I have dist directory that looks like this
Requirements: The root and each folder has .js and .d.ts for typing. I want to ship this to npm after obfuscating/minifying (to avoid reverse engineering). I need this to happen in place (all the folder structure intact), and also preserve the .d.ts. I use this package internally to develop and 1. need the flexibility to look into each folder directory, and 2. use the defined types.
What I've tried: I've tried webpack but since webpack minifies the whole codebase to one file, and does not preserve the typings file, I don't think it's the right choice.
Question: Is there a way to achieve this? Ideally the directory itself would almost be unchanged, just the contents would be minified. Thanks!
Related
I have a javascript codebase with a structure like this:
node_modules/
src/
/script1
/script2
/script3
package.json
package.lock
.env
etc...
The scripts are simple utilities that sometimes include code from each other's folders to maximize code reuse. Even if they didn't do that, they share the same node_modules folder so they are entangled anyway.
I want to run something like webpack on /script2 (but without targeting the web) so that all its unique dependencies are inlined as one massive JS script... (Or failing that, build its unique dependencies to output its own node_modules and package.json files... but that sounds way more complex).
How do I keep the current project structure but still build standalone pieces as needed, for different environments (mainly serverless functions)? Thanks.
Basically you can run webpack on each one of the files as an entry, and configure webpack to work with node target.
I am making an NPM package for the front-end and I want to know what the best file structure to use is. I have one code.js file and will have one code.min.js file. Should I have these two files in the root directory? In a dist folder? In a src folder? What is the best practice for this file structure - specifically on the front-end?
you should separate your source from your development compiled files, as much as possible.
For example on my projects, all minificated files, should be in a dist folder. The non minificated files, are not getting on the server. You wouldn't want a customer to accidentally use a non-min css and get 0.2 sec for extra load, would you? :)
Also, I do strongly recommend you to google this: "recommended structure [add framework name here]"
code.min.js is certainly the minified version of code.js. You simply need to add code.min.js to your project.
For node projects, you can insert directly the cdn link into your code or when you create a file ( js, css or image), it goes to the public folder.
How does Webpack know which files to include in library build? How does it know which files should not or should be included, as in miscellaneous files like images, examples, documentation, etc. If it automatically includes them how do we make Webpack ignore these included files?
Webpack scans the actual JS files themselves, starting at your entry point(s) and recursively scanning each referenced file, to determine what to build. It won't include any other files like examples or documentation unless you for some reason are include/requiring them from your javascript.
Things like CSS/LESS/SASS and images are built with specific loaders which generally also only build referenced files.
TL;DR: If it isn't explicitly included somewhere, it probably isn't in the build.
Question 1 :
I am installing my project dependency libraries using npm and it gets stored in the npm_modules folder. Is it necessary to keep the copy of library like angular.js,angular-route.js in lib folder or vendor folder? I could see few people are using lib folder or vendor folders to store the library in the permanent manner. I am confused by seeing this.
Question 2:
Do I need to copy/paste the node_modules folder to production or just run the npm install command on the project folder's command prompt to install all the dependencies in production. How does a dependency library get promoted to production?
Thank you kindly for your advice.
It all depends on how you need to deploy your site to production, really. Ultimately, you will probably want to bundle all your JS files into one or a few files, which are minified and sent with gzip compression.
How you bundle them is up to you. There are quite a few options:
Browserify
Webpack
Grunt / gulp build process
And many more besides
As to whether you need to keep a copy of these bundled javascript files under version control, well I think that boils down to 1 key question: can you run a build process (such as one of the tools using NodeJS) on the production server, or on a build server that creates a zip file or installer? If so, then you don't need to include them, just get the build server or production server to check out the latest copy from version control, npm install and then run the build process.
But if the best you could do is have the production server check files out from source control, then you would want to include the final versions of the files to use in the repository.
Keeping generated files, such as your bundled javascript files, in your source control repo should be avoided where possible. Because otherwise, every commit has to contain the changes to the source files, and the corresponding change to the generated files as well. And the latter is just noise, and has to be ignored by every developer looking at a diff/patch for a commit.
I'm starting with bower and followed this tutorial at first. I have no problems with installing a package, but with how to use it in a static web page.
I could obviously do something like:
<script src="bower_components/module_name/module.js"></script>
for each the components I need, but it seems to me not the good way to do. So I think I am missing something which could link the page generation to my bower components.
May be there a bower component which could help me to include all packages in a bower_components directory.
That is one way to do it but I usually use bower in conjunction with other build tools, like grunt or gulp. Then you can use a task, like grunt-bower-task, to copy only the necessary files to a directory of your choosing.
If you are feeling really ambitious, you could leverage the bower api to roll your own build solution that extracts the "main" files into your project.
Another thing to be aware of, is that not every dependency you will want to include will implement bower's configuration properly (example: missing main attribute or bower.json file). There will also be those projects that require you to include assets (fonts, images, etc.), which bower doesn't currently solve for. In these cases, you will need to come up with a way to move the files around. I always end up having to use something like grunt-contrib-copy to get everything in it's place.