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.
Related
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 1 year ago.
Improve this question
I am working on 2-3 react apps, and for each app when I run npm install, it installs a bunch of dependencies in the "node-module" folder which is approximately 250-300mb in size! It becomes really hard to deploy that on Github. Is there any way to reduce file size of node_module folder.
You don't need to push node modules to github, they should be included in your .gitignore file.
Within the root directory, edit .gitignore and add the line
node_modules/
Now when you push to github, the node_modules directory will be ignored.
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 2 years ago.
Improve this question
Question is related to javascript project which uses node and web pack.
I see in my current project there is node_module -> lib folder , there is xyz.js file in lib folder.
And in dist folder of node_module there is xyz.amd.js & xyz.main.js & respective js.map
I would like to know what is difference between amd & main.js files
And how the Current project which contains this node_module folder uses these files.
If you can point me to any site/tutorial explaining these. it would be helpfull
node.js will load those modules from local the node_modules/ directorywhen it encounters statements such as:
var xyz = require("xyz");
Or
import xyz from 'xyz';
"amd" refers to the Asynchronous Module Definition API, which loads modules in a lazy fashion (i.e. as needed). I suspect your xyz.amd.js module is for the AMD loader.
https://github.com/amdjs/amdjs-api/wiki/AMD
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 needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I know dist folder is used for production, distribution and what it should contain.
What i want to know is, when is the best time to use it? in what kind of work environment/project requirement i should use dist folder? like Heroku, what are the other platforms where i can deploy an app without dist and the platforms where i can't deploy without it (if there is any)?
I'm new to this, if someone can clearify the process would be very much helpful.
The dist folder is for production website it's not necessary to have it. It will contain for example your image, css, script, vendor folder ready for production (minified and concatenated).
You can check on google for this. Type "how to deploy a production React app to Heroku" for example.
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.