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 5 years ago.
Improve this question
I want to extend the npm run build command in my package.json not by replacing it, because it uses react-scripts build but by &&'ing another script.
Fastest way to achieve this would be a bash script which just does that. I want to copy a few other files from src into build in order to make a chrome extension out of it.
Is it considered bad practice to use a shell script here rather than writing it natively in a node environment?
Not exactly a bad practice and it is often done in practice but keep in mind that it will be less portable because it will not work on systems where the shell that you use for scripting (e.g. Bash or whatever is in the shebang line) is not available.
I recently wrote an answer to the question on how to solve a problem with installing Node modules that require Bash on Windows:
'bash' is not recognized as an internal or external command
So it is a problem that happens in practice.
Related
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
we have a lot of ts code which we can compile and run via "npm run dev". This allows us to hit the test js code via localhost. however, in the chrome debugger, 90% of the code is not visible (anonymous), and code which is not is too generic (such as find) to figure out how the thing which the debugger is showing as being slow or called a lot relates to our source code.
npm run Will execute one of the npm definitions in package.json
npm start is a script defined on package.json (same as npm run sart, its a shortcut)
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'm a little lost as to how I should proceed, actually I don't even know where to start.
I've been working on a few wordpress sites lately, usually I create a dev environment using npm grunt.
I set up a folder and do npm init. Then I install all the grunt plugins I need such as: watch, sass, uglify etc... I then download wordpress and set up the gruntfile.js so that for example my sass will compile to my wordpress theme's stylesheet. Just the usual (I hope).
The thing is rather than always repeating the same step over and over I'd like to automate it ( same config step for each site ).
So here is my question, how do you go about creating a script that will automaticaly install grunt plugins and configure them, download the latest wordpress and set up the theme files ( domain name etc...)?
I don't need an explanation on how to do all these steps but just a few pointers on where to start and what tools to use would be great. Being quite the novice in script writing any information is good to use.
Try yeoman.
There is yeoman generator for wordperss boilerplate. It uses gulp instead grunt, but has same idea that you need.
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
You write libraries using ES6/7, so someone importing the source would have to use Webpack + Babel to transpile the code.
You can get around that problem by providing the transpiled bundle. But then the problem is you would bundle in your dependencies, which the user may also have. Then the dependency gets bundled in redundantly for the user.
You want to preserve the
import MyLib from 'my-lib'
syntax so you don't want to provide two import paths.
What do you do?
You should just bundle your library. Even if the user happens to use the same dependencies that you use, most likely they will be using a different version, which might not work with your library.
If you want to reduce the size of your bundle, you should use Rollup.js—it uses tree-shaking, which basically means that your bundle will include only the parts of the code that you actually need.
After digging around, I found an excellent example:
https://github.com/reactjs/redux
Redux uses package.json prepublish to transpile the source code, without bundling it. This works perfectly as it no longer requires the user of the library to use babel, and at the same time does not bundle in dependencies.
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 6 years ago.
Improve this question
I looked into npm's package.json file and discovered that npm is actually just a node.js package which has a lot of dependencies such as lodash. This means the situation that happened with left-pad package that broke a lot of npm packages could affect npm too.
I see that there is some tendency: pip is written in python, RubyGems in Ruby, Composer in PHP, Maven in Java and so on. But is it good to write a package manager in the target language?
More specifically npm was written using npm - JavaScript has nothing to do the npm leftpad incident. I can't imagine them not using their own product for several reasons:
It's a tool for managing software dependencies. They must use one. Would you propose they use someone else's? Of course, if you trust your product you're going to use it yourself.
The leftpad "incident" was a policy flaw more than a software flaw which they obviously did not predict or consider to be a serious concern until something serious happened. Therefore, why would this be a reason not to use npm.
Of the hundreds of thousands of packages hosted it can't have happened too often or it would have been fixed long ago. That's quite impressive.
It was pretty easy to fix just be updating the caching policy and so it's not a threat to npm.
Other package management tools have had similar problems (or worse). For example, an entire maven repository went offline due to lack of funding. This is unlikely to happen to npm because it is centralized and there are many large stakeholders who are interested in making sure it stays up.
Incidents like these make the ecosystem more stable and mature.
Like all stories, this will blow over in no time.
The very reason is that npm is the default package manager for the JavaScript runtime environment Node.js
It is natural for the package manager to be written in the language of its runtime.
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 7 years ago.
Improve this question
so i completed building a new angular application and i would like to deploy it into production... of course i have prepared all my angular code such that it can be minified so i am covered there!! But something i dont understand... i have very good code separation and full unit testing of my application... as a result, of course, there are a lot of script tags on my main page.
I need to of course debug my javascript during runtime as i develop, but then when i go to deploy i need to minify. What is the best practice here? Is this literally a manually process of replacing the script tags with my all.min.js file after i move the code to the production machine? Do i minify all the css and html as well?? I am using gulp for the minification...
thanks for the help....
In the absence of server side templating (like Razor or Thymeleaf) I would suggest using gulp-preprocess, gulp-processhtml, or gulp-html-replace.
Use gulp to concat your files in development as well as production. You'll probably want to use gulp-sourcemaps to be able to debug your client-side javascript as if they were separate files.
Here's a sample gulpfile.js
gulp.task('script', function(){
gulp.src('./app/**/*.js')
.pipe(sourcemaps.init())
.pipe(concat('application.js'))
.pipe(sourcemaps.write())
.pipe(gulp.dest('./build'))
})
gulp.task('script:prod', function(){
gulp.src('./app/**/*.js')
.pipe(concat('application.js'))
.pipe(ugilfy())
.pipe(gulp.dest('./build'))
})
Then in your view, just point it at the build file.
<script src="/build/application.js"></script>
When you deploy, run gulp script:prod. In development, run gulp script.