@rigor789 it is a major change but i think it would be a good thing. Would that mean that a user can name the "main" css the way he wants? Would it not break the wepback config ? (currently having special handling of the app.css).
If we can get both running that would be great as users often dont understand they are forced to name their css app.css

Correct - the developer can put their css in any folder, with any name, as long as the import statement points to the correct path:

import "./styles/main.css"

@NathanaelA I actually think what is proposed here goes in the direction you want with no app.CSS forced
Now about doc,blog videos..... If we goes the way you want we can never make any breaking change...
Didn't N7 did exactly that ? There were breaking api changes and thus an video, blogs, docs... where not correct for N 7

I for one think the bundler was an amazing step forward. And going back to supporting a solution without it would require a lot of work to port and maintain all the steps that are necessary and current done through webpack. And there are a lot of them!
PS: we are absolutely not "bound" to webpack. We could very easily switch to "rollup" or other bundler.

@NathanaelA indeeed off topic. For the rest i ll let @rigor789 answer. But i think there were a lot of hard logics in the core just to "hard" load that css. This change makes the Core a lot easier to maintain

Hmm, I'm against this change for the reason that the app.css is documented in multiple books, web resources, blog posts, videos, etc

@NathanaelA this change would not affect any of those resources - playground, the default templates etc would still ship that default app.css and load it.

Each screen can also have its own custom css, and a app can easily load additional css files.

No intent to change this, apart from perhaps internal changes how it's handled.

I would like to see bundlers be optional, so having a standard entry point still make sense. 😀 Btw, Playground and other apps that need the ability to run outside of a bundled file would need a standard entry point.

I think this should be discussed in a separate high-level discussion - it's already possible, apart from NS7 now being esm (not going to go into details here)...

how does this actually move the framework forward enough to justify breaking all the existing documentation, examples, videos, etc?

This would not be breaking any docs, examples etc. The main drive behind this proposal is cleaning up the bloat in core that's fixated on a hard-coded app.css - unnecessary complexity and maintenance overhead.

We could take a less intrusive route, and refactor how core handles css in general. I don't see the need to handle application CSS and additional CSS (from css imports, theme switching etc.) differently like the core currently does. Everything is just CSS - and with your change from ~2 years ago @NathanaelA - we could explicitly use "tagged" css. When loading the app.css we could tag it as null (untagged) since it's global, and should never need to be removed.

With that in mind style-scope and Appliaction could be refactored and cleaned up to simplify things - like you said "Keep it simple stupid" - while keeping the loadAppCss method as a convenience wrapper for loading it.

And again - the point here is not about actually dropping app.css from being the default global css file - it's more about internals and how it's handled.

The original idea was to require an explicit import in the entry file (for bundled apps), and I still think that's worth it (for bundled apps) due to the way bundling works - but we can easily make it non-breaking if we only focus on the internals.

Hello if I may interject.

I think rather than importing css in your app entry file. What if your global css was specified in the nativescript.config.ts? Something like this:

// nativescript.config.ts
export default {
  id: 'my-app-id',
  appPath: 'app',
  appResourcesPath: 'App_Resources',
  // path to global styles can be added / changed here
  css: [ './app/app.css', './styles/some-other-file.scss' ],
  android: {
    v8Flags: '--expose_gc',
    markingMode: 'none'
  }
}

I'm a big user of NuxtJS and this setup is similar to how they handle global styles (See here).

I'm not super familiar with the source code of Nativescript/core (just been poking around a bit), but since this config file is already being imported into the Nativescript app when it's bundled, it would be trivially to import the css with the paths provided here and it helps remove the "special handling" of app.css. Additionally, it would also be trivial to migrate old projects and templates to this method. (ex: templates have css: ["./app/app.css"] included in the config by default)

I think there are other benefits to specifying the global styles in the config file and they are as follows:

Lower Cognitive Overhead

Developers will naturally look at the nativescript.config.ts. They will see the css property accepts an array of string and from that info alone be able to understand how to change / add new global stylesheets. Sure documentation will still be necessary but it's way more intuitive than searching the docs and finding the Application.setCssFileName method. Which brings me to the next point

Global Style Config Standardization

From the current Nativescript docs concerning Application Wide CSS. It looks like each flavor of Nativescript has a different method for changing your global stylesheet:

// javascript / typescript
import { Application } from '@nativescript/core'
Application.setCssFileName('style.css')

Application.run({ moduleName: 'main-page' })

// angular
platformNativeScriptDynamic({ bootInExistingPage: false, cssFile: 'style.css' })

There's also not any documentation on how to accomplish this with Vue, React, or Svelte. So would the method be different as well or is there overlap?

However by moving global style configuration to the nativescript.config.ts this configuration option gets standardized across all flavors making for a simpler developer onboarding experience.

Anyway that's my counter proposal.