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.
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 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.
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 4 years ago.
Improve this question
New to TypeScript here and just wondering what the community views as best practice.
When I compile for production, I use the webpack loader. However, when I run my tests, I need to run tsc && ava. This generates a .js equivalent file in the same location as their .ts counterparts. Should these by committed to the repo alongside the .ts files? My first assumption is no because they should be re-compiled each time before a process e.g. starting your server or executing tests is run. However, I'd just like to get the community's opinion on this.
Your assumption is absolutely correct - build artefacts and outputs shouldn't be added to your repository. The main reason for this is that it's easy to end up in a situation where the source .ts file has changed but the compiled .js file differs because it's not been committed at the same time.
You also add complexity to your pull-requests/merge reviews, as there will be a large amount of generated code that isn't really part of the review but is in the changeset.
Finally, merging changes becomes a bit of a pain, because you need to recompile the .js files for every merge you do.
If you only use .ts files in your source directory, you can add /**/*.js to your .gitignore to prevent files from being added accidentally.
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 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 6 years ago.
Improve this question
I've got some basic questions concerning the project structure of a MEAN-app including Angular2. I've followed the starting tutorial of angular.io to build a really basic Angular2 app. Now I try to integrate this app inside a NodeJS project following this tutorial. The problem is that this tutorial was written at the time of the first Angular.
My questions are:
where should I put the npm packages of my Angular2 app? Inside the
public folder (so the app has an own packages.json) or inside the
node packages.json?
how should the tsc compiler should be implemented?
Bruno
I've had a very similar problem, when first starting to migrate towards angular2. The Angular.io tutorial uses System.js for its modules, which is basically incompatible with Node, which uses CommonJS. This leaves you with two options.
Setup the Typescript compiler and Node modules for Client and Server individually.
Use CommonJS modules with something like Browserify on the Client.
Now for me, only the second option is a good option. Setting things up twice defeats the whole purpose of having the same language across Client & Server.
I have prepared a Boilerplate for Angular 2 to start with Browserify quickly.
You can check it out right here.
Now all you have to do is create a public folder for your client app and also create static routes for your node modules. It could look something like this:
app.use(express.static(__dirname + '/public'));
app.use("/node_modules",express.static(__dirname + '/../node_modules'));
Personally I use a VS Code Task to compile my Typescript and then use Watchify on the client side to bundle it all together. On the Server Side I use nodemon to watch for any changes and restart the Server on compile.
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
I'm building a web application using a MEAN stack: MongoDB, Express, Angular, and Node.js, based on Daftmonk's angular-fullstack Yeoman generator.
Because most of my work is Java, I'm using IntelliJ IDEA however I'd like optimal introspection and workflow for this JavaScript module.
In order to achieve to most possible introspection, and least possible confusion, what plugins and project configuration should I use?
Here's the best I've been able to do so far.
There are some crucial IntelliJ plugins to install:
.gitignore support
AngularJS
Base64 for IDEA and Storm
BashSupport
Bootstrap
CSS Support
Database Support
ddescriber for jasmine
Git Integration
GitHub
HAML
Heroku integration
HTML Tools
Jade
JavaScript Debugger
JavaScript Intention Power Pack
JavaScript Support
JS Toolbox
JUnit
Karma
LESS CSS Compiler
LESS support
Markdown
Mongo Plugin
NodeJS
Require.js plugin
REST Client
Spy-js
SvgViewer 2
Terminal
W3C Validators
YAML
As a peace offering to the mighty IntelliJ, use Java as project SDK:
I prefer to configure four separate modules, to help separate back-end vs. front-end JavaScript dependencies:
Add the bower_components library to the client module, and the node_modules library to the server module:
And be sure to enable JavaScript libraries in the editor.
Per best practices, we do not commit the local IntelliJ IDEA configuration folder (/.idea/) to the repository, instead adding it to the .gitignore file like so:
# IntelliJ IDEA local workspace
.idea
Happy coding!