Splitting globals into smaller chunks and removing side-effects #6
Replies: 4 comments 3 replies
-
I'd be curios if we could "autoload" globals with https://webpack.js.org/plugins/provide-plugin/ or a custom loader? |
Beta Was this translation helpful? Give feedback.
-
We can, but it's probably a bit too much work. As I see it, you have to individually provide each polyfill like this:
and I don't think calling I believe this can be done better with adding the polyfills to the application entrypoint:
webpack has a couple of ways of doing it, maybe this one can work too: https://webpack.js.org/guides/shimming/#global-exports |
Beta Was this translation helpful? Give feedback.
-
@edusperoni I don't think that'd be a huge deal given the new webpack implementation I'm working on - we can extract a function that generates that object for all globals if we decide to go that route. I think it would be convenient! The entry way is also feasible as long as it does it in the right order? Definitely worth trying the different options before we decide on either. |
Beta Was this translation helpful? Give feedback.
-
Yeah. That's what we're going for with the angular webpack: const entries = [ './src/main.ts' ];
if(fs.existsSync('./src/polyfills.tns.ts') { // .tns depending on code sharing or not
entries.unshift('./src/polyfills.tns.ts');
}
...
entry: {
bundle: entries
} This will allow us to have a place where the developer can also add some polyfills of their own, like |
Beta Was this translation helpful? Give feedback.
-
The current globals file is a side-effect of
@nativescript/core
. This is especially an issue in workers asui-dialogs
will pull most of the core into the worker chunks, which can't even display dialogs.Proposal: split globals in:
Remove the globals import from
@nativescript/core
.Change the way globals are imported:
@nativescript/core
or inside workers (angular flavor will likely go this route, at least for non-worker polyfills)@nativescript/core/globals
is being imported beforemain.ts
and the core team will maintain which polyfills are required for workers and webpack will also ensure they're polyfilled on each worker.Breaking changes:
The split itself will generate no breaking changes as the functionality of
index.ts
will remain the same.After removing the import from
@nativescript/core
, approach 1 will require the polyfills to be specified by the developer while approach 2 will required the user to upgrade to the latest webpack release.Beta Was this translation helpful? Give feedback.
All reactions