I am trying to find out if I need to use option of {loadMaps: true} in initialization. Help isn't clear about when and why you would need this option: https://github.com/floridoo/gulp-sourcemaps#load-existing-source-maps
I'm running gulp watch task which builds my project on any file changes without this option and it is overwriting source maps with new changes. Right now my project is small so I am not sure if this has visible performance impact in large projects and it is recommended to set it to true.
Related
Writing an NPM package containing es6 modules, is it best practice to keep the source files separate
package.json
esm
index.js
Content1
Content1A.js
Content1A.js.map
Content1B.js
Content1B.js.map
Content2
Content2A.js
Content2A.js.map
Content2B.js
Content2B.js.map
with index.js referencing contents in subfolders, or is it better practice to bundle it into one file
package.json
esm
contents.js
contents.js.map
Seems the first method has an advantage with CommonJS modules since it gives a consumer possibility to import directly from the source and thus skip unused imports from index.js (since CommonJS modules are not tree-shakeable) but with es6 modules, this argument disappears.
Different bundlers might be capable of different things. The rest of this answer refers to Webpack which, being one of the most common bundlers, should influence decisions in this area.
The most important factor governing the decision about whether to bundle your library or not should be related to tree-shaking. No other important aspects come to mind for me.
Parameters affecting tree-shaking in Webpack
sideEffects: false
Setting in package.json that indicates whether modules in the package have side effects which needs to be executed when the module is imported but not consumed. Setting it to false indicates that no modules have side effects. May also be set to a list of modules which have side effects and other more complex values. Default seem to be true indicating that all modules have side effects.
This parameters plays a large role when using an entrypoint index in your package, from which all package exports are re-exported. Sparse imports from this index could easily cause your entire package to be bundled if this setting is not correct.
optimization.usedExports: true
Setting in webpack.config.js indicating to Webpack that all exports that are not used may be excluded. This activates a heuristic used by Terser to remove unused code inside a module. Is set to true by default.
In toy scenarios, this setting might seem efficient enough and the sideEffects flag might not seem to play a big role. This is not the case in real scenarios with more complex code where it is harder for this heuristic to do a good job.
/*#__PURE__*/
Annotation to be used before statements (such as functions) to indicate that they can be excluded if not explicitly used. These annotations also play a part in the heuristic used by Terser to remove unused code inside a module.
Conclusion
To allow your consumers to benefit the most from tree-shaking, it seems advisable to not bundle your es6 npm package and instead let the separate input modules remain separate so that the sideEffects setting in package.json may result in the consumer bundler to prune as many unused modules as possible. Rely on optimization.usedExports inside modules, evaluate bundle content and add /*#__PURE__*/ annotations where you think it could make a big difference. If everything is bundled in the same file, the sideEffects flag in package.json can't do the main part of the job as everything is in the same module and subsequently we have to rely on a lot of additional /*#__PURE__*/ annotations and heuristics in the consumer bundler to make tree-shaking as efficient as possible, which requires more from you (in terms of annotations) and does not come with any particular advantage. Remember to build your package in production mode as optimizations are not always active otherwise.
Source
https://webpack.js.org/guides/tree-shaking/
Own experiments
I'm building a VUEJS dashboard and I want to generate multiple versions from this. I want to be able to load different logo images and titles. I'm building my app with vue-cli-service build but after an hour of googling I'm still in the dark how to configure the build process to make this possible. Is there somebody who can point me in the right direction?
I've read the docs about the target parameter, but I couldn't figure out how to make a different build. I just got the same in a different directory.
depending on your setup it might be a lot easier to use vue-js to change titles and images depending on the domain/path/env whatever.
if you MUST have a static build than you can find an answer here: How can I create two separate bundles with vue-cli 3?
Probably a little late to the game, but I expect what you want is to use modes and environment variables. It's documented very well here https://cli.vuejs.org/guide/mode-and-env.html.
Only variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. You can access them in your application code:
console.log(process.env.VUE_APP_SECRET)
During build, process.env.VUE_APP_SECRET will be replaced by the corresponding value. In the case of VUE_APP_SECRET=secret, it will be replaced by "secret"
You can set the paths/values of things you care about with env vars. You could also have each different build as a 'mode' and maintain env vars for each use case.
If you modify a file under src/python, then a rebuild is necessary, unlike modifications to configs/
That makes making changes under that directory very painful, since even the clean rebuild takes several seconds.
Is there a way to avoid the rebuild?
M5_OVERRIDE_PY_SOURCE=true
If you export that environment variable for the run, and gem5 uses the Python source code directly.
This likely exists because by default, gem5 packs up Python object files inside the gem5.opt binary so allows users to run it without changing their PYTHON_PATH.
How M5_OVERRIDE_PY_SOURCE works is described here at 252dd80.
Tested on: https://gem5.googlesource.com/public/gem5/+/91295ff980c17efb3ad013b9636017b58e49c071
I'm using ng-bootstrap in my Angular project.
The problem is that ng-bootstrap is still in its early stages and missing lots of functionality. I have added a simple feature within the code in my node_modules/#ng-bootstrap directory.
The trouble is that I worry that if/when there is an update to ng-bootstrap and I update my project with it, my local changes in the functionality will be overwritten and lost.
What are some techniques to deal with this problem?
You've effectively just created your own "branch" of that package. You could submit a pull request if the functionality is something that should be there for everyone. Since you have custom changes, you're responsible for making sure updates don't overwrite them.
If i needed to so something like this, i'd see if there was a way to implement the changes without modifying the ng-bootstrap files themselves. Without knowing what the change is, i can't say how that might be accomplished. One option there is to not use a package manager for that framework, or let the package manager get the "official" files, and then copy them somewhere else that you actually use. You're still responsible for making sure to merge changes in when the framework updates, but at least it won't be automatically overwritten.
Is this possible using v1.6.1? Due to the Xdomain configuration of my client's dojo deployment, it is necessary to execute a new build each time dev code changes. As you can imagine, this is a huge time waster.
From everything I can see there is no way to exempt the core from the build playing by DOJOs rules. So I am wondering if there is a way to break the rules (modifying the Rhino calls?) to get to where I need to be.
A couple thoughts.
You can avoid building most of dojo (dijit, dojox) but I imagine you already know that
This restriction you are facing seems odd. Isn't there some way you can just upload the specific JS files you are editing during development?
Maybe if you give more details on the client setup, I can help you brainstorm a way around this problem.
Update
Here's what I think you need: Customize Dojo Base in Build. This allows you to specify particular bits of the dojo base to include.
This works in pre-1.7, so you should be good.
Appears to be exactly what you want:
layers: [
{
name: "dojo.js",
customBase: true,
dependencies: [
]
},
// ... remainder of profile
]
This will give you the absolute bare minimum of dojo (which you still don't need for your dev scenario, but which will drastically reduce the amount of files processed).
For other use cases, you can use the dependencies attribute to add in other stuff from dojo core.
Update 2:
Here's a couple build-time optimization suggestions:
1) Don't intern strings, and don't compress, when in dev.
There are arg values you can pass to avoid these time-consuming steps (example is for ant build):
<arg value="internStrings=false"/>
<arg value="layerOptimize=false"/>
2) Build to a ram disk to speed copying of files
Dojo supports mix-and-match - so you can use xdomain and/or custom build for the stuff that does not change - and use regular dojo.require for the JS/widget that is changing often - and then just push that JS to see the change without a new xdomain/custom build/deployment
You can explore using local modules with xdomain build. Also, Dojo allows using multiple custom builds - so you can do a stable custom build for the widgets that don't change so much and another smaller build for code that is changing frequently.
Why not use dojo 1.7, load asynchronously, and rely on it's legacy support? http://livedocs.dojotoolkit.org/loader/amd