Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I got a components library that will be published to npm to be consumed by a razzle app. My main question that I want opinions on best practices is, should the packages be built with cjs or esm, and what is the downsides of each?
Am I fine with only building to cjs?
ESM
Tree shaking
More understandable in code.
Allows lazy loading of the component
Gives more easily the ability to import a certain part of the code.
cjs
Cross build
Supported on more environments
If its no problem for you use both. One for every environment. CJS would work on most environments.
If your target is only react or other frontends es6 gives you all the advantages above. But if you want you component to be usable in javascript webpack like legacy apps you should use cjs, also for the backend.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
As most of programmers:
I write my source-code in ES2015+ or TypeSCript
I transpile my code in ES5
I publish the transpiled code as an npm package.
The support of ES2015 is now widely spread. The maintained versions of node.js support ES2015. In the browser land ES2015 seems also widely spread.
Publishing packages in ES2015 has advantages such as smaller bundle size and native support for ES2015 features.
Do you know any issue to publish packages in ES2015?
Have you some npm statistics about the proportion of ES2015 published packages?
Findings
In the past, packages were published in ES2015. This produced some issue on the client side. Bundler users seem to assume that the code published on main and module entries are ES5-compatible. Thus, they exclude their packages' dependencies from the transpilation process.
It seems difficult to publish an ES2015 package since this changes how clients consume the package. However people and tools start to figure out the issues of this legacy inheritance, and search new ways to tackle it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are many JS libraries and frameworks (e.g. jquery) that suggest doing this:
npm install foo
This gives you a node_modules directory in which there would be a foo directory. For most JS libraries that are meant for use in web pages, there will be a dist directory inside consisting of the required JS files that can be used.
I can now include JS with something like <script src="/node_modules/foo/dist/foo.js">, but I haven't found a single website doing that. Of course, this folder could be symlinked to something like js and then that could be used as js/foo/dist/foo.js, although I'm not sure if this is a good idea or whether it is even done in real life.
To me, copying scripts from online sources and putting them in my project repository seems like a better idea, although the advantages of automatic package management are lost in that case.
I do understand the workflow of npm when developing node.js-based server side applications, however, I'm having trouble understanding where the case involves scripts to be included in web pages. What exactly is the workflow in such cases?
Well, do use NPM installed scripts in a web you have to use some bundler/builder which adds additional layer package management in your application. This would allow using modules like in server side. After bundling your modules into single or multiple chunks include these in your web like any other JavaScript files.
There are multiple tools for such job:
http://browserify.org/
https://webpack.github.io/
http://rollupjs.org/
Loading JavaScript in the browser is usually done through a module system, for which there are several competing standards (AMD, CommonJS) and implementations. One such implementation is Browserify, which assembles (at build time) the scripts you actually require into a single bundle.js file, which you can then easily include in HTML. (Other module systems work differently, for instance by loading each file separately when it is first needed).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am curious as to what the best practice is to combine all JavaScript into one file. I am using Visual Studio ASP.NET MVC 5 and TypeScript. I also have jQuery and a bunch of plugins, as well as my own page specific JavaScript fies.
Visual Studio has an option under Build Options -> TypeScript Build to "Combine JavaScript output into file".
Does this combine only the JavaScript generated from the my TypeScript files, or will it also combine jQuery and the various plugins?
Is there any possibility for collisions (multiple .ts files having the same variable name), or does TypeScript natively avoid that?
The typescript build option (--out in tsc) will only concatenate the typescript within the project. You may run into issues with file ordering if you use this. Using CommonJS with browserify solves this issue, though the TypeScript project itself uses the --out option for building the typescript compiler. Nevertheless this will not concatenate your vendor library files like jQuery.
The best option is to use gulp or grunt as part of your build process to concatenate and uglify your compiled Typescript and Javascript.
You should not be using global variables and thus will not have variable collisions. Instead your code should use modules. This can be the traditional javascript module pattern which is equivalent to Typescript modules, or the AMD modules like Require.js or CommonJS modules which actually are better suited for concatenated code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
In VS2013, intelliSense in a NodeJS App in a *.js file works like a charm. I was wondering if there is also intelliSense supported in a TypeScript file for several NodeJS-Modules? How can I enable intelliSense for NodeJS in a TypeScript file?
DefinitelyTyped is the place to look for typescript definition files:
https://github.com/borisyankov/DefinitelyTyped/tree/master/node
You can use your favorite package manager to get it and all of the DefinitelyTyped deffinitions are available in NuGet.
There are a quite a few specific NPM modules on there too, but some you will have to define yourself.
In VS2013 when you add a deffinition file (*.d.ts) then it will be available from the IntelliSense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have gone thru the intern-tutorial which is a very simple unit test case. However, it's not clear to me if the directory structure can be different and how flexible intern's configuration can be to accommodate it.
I'd like to find a tutorial that showed the v1.1 intern locations expected... which locations are mandatory and which can be modified and how that impacts the config file (intern.js) settings. What is the directory structure intern expects for a project and what is changeable, such as when you have multiple packages even.
In particular I'd like to see the relative location relationships of the:
web root
intern dir
intern.js config file
unit-test files
dojo/dijig/dojox/etc package location
modules in a package
Please show how placement relates to the configuration settings if possible.
As of Intern 1.1, the only thing that is mandatory is that Intern be installed as an npm dependency of the root project being tested. There are no relationships to any of the things you asked about, except that everything needs to be within the project’s root directory.