tree-shaking | Build this project

It looks like these warnings are generated when there are no global variables named __VUE_OPTIONS_API__ and __VUE_PROD_DEVTOOLS__ (see code).

In a webpack setup, you can inject global variables at build time with the Define Plugin. Unfortunately, I'm not aware of any parcel2 plugin (yet) that does this (although it would be pretty simple to write). However, you could just create them yourself by writing this near the beginning of your app's entry .js file:

The meaning of this warning message is that you need to specify the flag explicitly in the bundler when you do a production build.

Please refer to the following link for packages provided by vue-i18n for bundlers.

https://vue-i18n.intlify.dev/installation.html#with-a-bundler

One advice to help you out is to use the plugins for each bundler listed in the NOTE section of the above link, and they will configure them properly for you. I recommend that you check them out.

Checkout this issue listed in GitHub forum.

After discussing the problem with my peers, we figured that the reason for it to be in the bundle is that because environment.production is evaluated at runtime, tree shaking will not remove the module from the bundle. Event though it is not really used.

There is a way around it though.

first create 2 files:

one to host the import array for non-prod (default), with the following contents

src/hat-trick/store-dev-tools-import.ts

I understand that this questions might be highly dependant on the situation you're in but still thought I'd share my process.

Usually when you build, your framework outputs the sizes of the built artifacts. In the case of create-react-app, these sizes seem to be the size of the gzipped versions.

You may also check your browser dev tools and note the sizes of the downloaded bundles which are typically NOT the gzipped sizes but the actual sizes.

When factoring something out or doing some sort of comparison, take notice of the different sizes before the change and after the change. Given some sort of intuition as to how these sizes should change evaluate if this is the case or not.

With NextJS you may use @next/bundle-analyzer, in most other cases you may use source-map-explorer. The latter uses source maps to map bundled code to sources; if the source itself has source maps, then these sources are used, otherwise you will see references to node_modules. With source-map-explorer, it might be worth both looking into the visual representation as well as the json representation since, with a lot of sources, the visual representation might suppress the participation of a certain component or library which the json representation will not.

With source-map-explorer you may make some valuable comparisons between different versions of an app.

After establishing with, for example, source-map-explorer that some source code expands more in some context that in another, you may want to research the issue further. Using source maps (either in development mode or in production mode if you have them available there), you may want to track the imprint of a certain portion of source code in the output bundle. A lot of browsers support mapping bundled code to source code (given source maps) but not all allow you to do the opposite. Firefox, however, has this feature and it allows you to, given bundled code, view the source code and vice versa. This is very useful when you're trying to track what some source code actually results in in the output.

Well, the following is a list of what caused the increased size in my case:

• I imported from an index in my package and the index imported all of the exports of the package. This should not be a problem with esm modules, but without the sideEffects: false flag in package.json there were some ambiguities. Even though the unused sources from MY package were not added to the output bundle, some indirect dependencies could not be ruled out as not having side effects, so these were added to the bundle, even though the component that imported them were not even used. Adding sideEffects: false to the package.json of my package solved this and reduced the package size.

• When keeping the components in my main project that was bundled using create-react-app, some convenience methods added by Babel in all transpiled files were removed thanks to the presence of @babel/plugin-transform-runtime plugin. This plugin removes these convenience methods, given that some Babel runtime was guaranteed to be present when running these files (from which they could be imported instead). When the same configuration was used for the factored out components, the size shrank even more.

• Finally, at the time of this writing, the tsc compiler seem to output more verbose code than Babel (see TypeScript: tsc transpiles jsx to more verbose code than babel). When transpiling the package I first used tsc and after started using Babel, the size shrank even more.

All in all, with the above changes, the output ended up being just 1.7 kB larger (unzipped) than before the refactoring which was a both understandable and acceptable result.

I'm using svelte with codeigniter as well and there is a simpler way to include your css framework:

1. List item add the stylesheet to the view (layout) header and the script to its footer just above the build of svelte's script file (if you are going to use shoelace in the whole project).
2. add both to if you want to target only one page (even though you can also do that from the controller before loading the view to target certain pages).
3. you can add it by installing npm i svelte-preprocess node-scss then include the scss file of you css framework and just inport the js file (and also you can do that using your global stylesheet using scss).

The "main" entry in a package.json file should always be in commonjs format. The "module" entry should always be es modules. Right now, you have "main" pointing to es modules, which will not be resolved properly (your ts-node error, for example).

Generally, if you want to give consumers the option, you would create 2 builds in the distributable.

(you'll need to remove the comments in these json files)

I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?

Yes, that's the general idea. You make changes to script files on your local machine (or network), and then in order to see the changes take effect, you rebuild the app so that a new bundle is generated. This bundle can then be hosted on your web server or development server, and once it's there, you can refresh the page to see the differences.

But almost all of this can be automated, resulting in it not really being much of a chore at all.

• Nodemon is a popular tool that watches a directory for changes and can run Node scripts when a change is detected. With it, you could, for example, make a change to a file, and then it'll automatically rebuild your app.
• For Webpack in particular, there's webpack-dev-server, which can automatically refresh a page when the app gets rebuilt.

So, during development, the workflow can be as simple as - make a change, then alt-tab to your browser (hosting the app on localhost) to look at the changes.

Bundles built for the purpose of eventually hosting them on the front-end can easily incorporate Node modules - the build process can take the code from the module, and the bundle produced can include that code. This sort of thing is extraordinarily common.

It appears that declaring "sideEffects": false is the responsibility of each package an application consumes, so setting it in the application's root package.json isn't enough.

The package.json of @yamato-daiwa/es-extensions needs to include "sideEffects": false, so applications know that package is side-effect free. I tried this in your first example repo, and the final build gave me the expected:

I believe that enums camed to TypeScript from C#. In general numerical enums in TypeScript are unsafe. Consider this example: