If I've install JSLint through NPM globally, is there a way to disable certain rules either within the current scope of my application or globally on my system?
The main issue is the dangling underscore problem. I mean, the main place this comes up is in node.js when i use __dirname, but I am sure it will come up for underscorejs as well. I've ignored it with a jslint directive, but I think it is a little annoying to need to do that on every file I use underscore.
For that matter do I need to place 'use strict'; at the top of every single file?
Consider using a build tool for lint configuration and automation. When your project grows, you will need one anyway.
For node.js projects, I recommend using grunt. Install grunt into your project:
npm install grunt
Grunt has a built-in task for lint (https://github.com/cowboy/grunt/blob/master/docs/task_lint.md).
Now create a grunt.js file and configure linting there:
module.exports = function(grunt) {
grunt.initConfig({
lint: {
all: [
'app.js',
'modules/*.js'
]
},
jshint: {
options: {
nomen: false
}
}
});
grunt.registerTask('default', 'lint');
};
Note how you can add easily multiple files and file patterns and apply options globally to all of these.
Now you can just run grunt by invoking:
grunt
Note that if you use jshint, nomen is off by default (http://www.jshint.com/options/).
Related
I'd like to disable/not install one specific npm package in my app when CircleCI runs its tests, because the package makes the build process fail.
To be specific, it is a babel plugin for react-intl that automatically parses the files and pulls strings in another folder (babel-plugin-react-intl).
What is the best way of achieving this? Can this be done in the .babelrc file for example?
How you install and run tests locally should be the same as your CI setup.
If you need to disable a babel transform for tests - have them run as a different NODE_ENV and make sure your .babelrc only includes the plugin for the specific NODE_ENV
eg:
{
"env": {
"production": {
"plugins": ["react-intl"]
}
}
}
See: https://babeljs.io/docs/usage/babelrc/#env-option
I've converted to npm for my build system: no gulp etc. Also no webpack, rollup etc, it's an es6 system based on modules & no bundling. Sure is simple!
Obviously I don't want to drag around a node_modules hierarchy for my run-time, front end modules. And don't want to import foo from './node_modules/god/awful/path.js'. So I'd like to have a top level directory for the run-time, front-end dependencies.
So how do I copy my "dependencies", not "devDependencies", to a top level directory for deployment?
I've got a run script that can do it but it's pretty messy and the location of the package under node_modules is not always obvious. Maybe there's a package for doing this automatically? Or a nifty npm trick of some sort?
OK, I'm starting to need this even more than before so thought I'd nag and be clearer about what I seem to be forced to do.
First of all, I use no workflow task managers, just npm run scripts in package.json.
My dependencies (npm --save .. not --save-dev) are:
"dependencies": {
"lzma": "^2.3.0",
"pako": "^1.0.0",
"three": "*"
},
.. and my scripts cli for hoisting the dependencies into a top level libs/ dir is simply a huge cp:
"build-deps": "cp
node_modules/lzma/src/lzma.js
node_modules/lzma/src/lzma_worker.js
node_modules/pako/dist/pako.min.js
node_modules/three/build/three.js
node_modules/three/build/three.min.js
node_modules/three/examples/js/controls/OrbitControls.js
node_modules/three/examples/js/controls/FlyControls.js
node_modules/three/examples/js/controls/FirstPersonControls.js
node_modules/three/examples/js/libs/stats.min.js
node_modules/three/examples/js/libs/dat.gui.min.js
libs/",
This is pretty primitive: I have to find the dependencies in node_modules (not always obvious) and add them to the list by hand. Sure makes me want fewer dependencies! :)
I know that bower is designed for "front end" dependencies (--save in npm speak). But it seems like npm would be perfect for dependencies, and yet it appears I need to be this primitive.
What am I missing here? What do you do?
This is something I wrestled with in my earliest forays into development with Node packages. I had the exact same idea you had: "I can use npm to pull in whatever I need for my project, great!" and then trying to manage how I reference each of my dependent libraries. I didn't properly grasp at the time that npm wasn't just there to help me fetch my dependencies, it's also there to help me manage them.
Here's the long & short of it: you do NOT want to be copying anything out of your node_modules folder to some other, more human-convenient location. There's a lot of reasons why, but the biggest is that you don't need to copy anything out of node_modules -- everything your project needs is right there.
When you're developing in ECMAScript 2015+ you should only ever have to do the following (apologies for the overly-simplistic code):
/* N.B. These all reside under node_modules, yet I don't
* have to spell out their paths under node_modules: */
import $ from 'jquery';
import _ from 'lodash';
import moment from 'moment';
import NiftyLibrary from 'niftywhatever';
// ... code ...
let $name = $('#name');
let now = moment();
// ... other code ...
In other words, your development environment setup should just handle the module resolution for you. You should never have to specify that the jQuery library you want to use is at "node_modules/jquery/dist/jquery.min.js". If you're doing this you should take a minute to figure out why you're doing this -- it's unnecessary, it's a time- and brain-suck and you'd rather be writing your application code than managing your dependencies ... NOT managing the node_modules tree.
You mentioned you're developing with ES6 modules, but not using webpack, gulp, Grunt, rollup or any other build or bundling tool. Is your project intended to run entirely in Node? I ask because the last I heard most browsers aren't quite ready to run ES6 modules natively. So how are your modules getting transpiled to ES5? Maybe you're approaching this in some novel way I haven't heard of yet, but in my experience a build or bundling tool is necessary. (Also, it's a heck of a lot of fun.)
I've used Grunt with RequireJS in the past, but am now using webpack 3 with Babel and a few additional loaders (depending on the type of project I'm working on). I use npm scripts to handle my top-level tasks (running a development server, building a finished distribution package, running tests, etc.), but I let webpack handle all the business of transpiling ES6 into ES5, translating Sass styles, precompiling Vue components, etc. It's a bit of work to wrap your mind around the webpack approach, but it's well worth the effort.
Maybe webpack doesn't fit your style -- fair enough. But there are a number of other tools you could use instead. They all require a little time to get acclimated to their approaches, but they should all be able to take care of module resolution for your dependencies. Once you get a build environment set up correctly it should cease being a visible part of your development workflow; you'll just reference your dependent libraries by their names, map them to a module-local variable and use them.
Is this helpful?
EDIT: This is webpack-specific, but there should be similar options available with other bundlers or build tools.
In webpack you can use the copy-webpack-plugin to copy npm-sourced dependencies to a separate folder. This can be useful within a service worker, for example, where the execution context is a little different.
What I would suggest is scoping your dependencies (#frontend/...) and symlinking the scoped folder to your top-level dir in a post install script (similar to how bower handled the transition to yarn: see https://github.com/sheerun/bower-away)
Example:
...
"dependencies": {
"#frontend/jquery": "npm:jquery#~3.4.1",
},
"engines": {
"npm": ">=6.9.0",
"node": ">=12.10.0"
},
"scripts": {
"postinstall": "node -e \"try { require('fs').symlinkSync(require('path').resolve('node_modules/#frontend'), 'static/bower', 'junction') } catch (e) { }\""
}
Requires NPM >= 6.9 for alias support.
FYI: aliases break audits
I'm looking for a more efficient way to deploy my WordPress themes. Right now I create the theme and when finished I copy the contents into a new folder without all my Node, Grunt and other dev files. My dev environment runs on DesktopServer, which has an auto-deploy option, but this also copies unwanted dev files.
Could I use Grunt to create a task that when fired copies specific files and folders from /themes/dev-theme/ to /themes/production-ready-theme/ ? This way I have a clean theme that can easily be zipped or uploaded to the production server.
Update: I just thought of a possible solution to run grunt-contrib-copy from my themes directory. This Grunt module would let me control which files to copy. But perhaps there is a more clean or efficient method to accomplish this task.
By using the Grunt Shell module you could simply add this to your grunt file:
grunt.initConfig({
shell: {
moveTemlates: {
command: 'mv /themes/dev-theme/* /themes/production-ready-theme/'
}
}
});
The grunt-contrib-copy module does have the possibility to copy files up the directory tree after all. I just tried it out using these setting in my grunt.js file and it worked.
Grunt Shell gets the job done. But if you already have grunt-contrib-copy installed in your project you could just use this.
copy: {
main: {
src: ['css/*', 'img/*', 'icons/*', 'js/*', 'lang/*', 'lib/*', '*.php', '*.css'],
dest: '../production-theme/'
}
},
Is there a way to write a single module/package that can be posted both to npm and Bower, without having to duplicate files?
Imagine you have a simple JS file with some code that is self-contained (i.e. it doesn't have any external dependencies).
An ideal directory would look something like:
/file.js
/package.json
/bower.json
The problem in this case is that "file.js" to work with npm would need a module.exports statement, whereas this would not work with Bower.
So, is there a way to avoid producing two separate almost identical files?
This seems the best option so far (inspired by the Angular team).
Create an index.js file in the project root, with this content:
module.exports = require('your-original-module.js');
Then, in package.json add this line:
"main": "index.js",
Simple, but effective!
If your module doesn't depend on other npm modules,
you can provide file (lets call it 'bowerify.js') with
window.MyUtility = require('./file');
to expose your utility as global variable.
And then use browserify to package your code for the browser:
src: 'bowerify.js',
dest: 'my_bower_module.js'
Now you can install my_bower_module.js with bower.
I've set up a jenkins CI server on a windows box for one of my projects. There is a portion of it written in Coffeescript. Previously this part wasn't looped into the build process. Now It needs to be.
I haven't seen any coffeescript plugins for jenkins, or much from google on the topic of building coffeescript in jenkins.
I am looking for the simplest way to set up a jenkins build to include a coffee compilation step. Preferably through plugins on jenkins rather then manually installing programs on the box.
Currently the coffeescript is compiled via commands like so
coffee --lint --watch --output "C:\repositories\martha\trunk\bb\app\bin\js/" --compile "C:/repositories/martha/trunk/bb/app/src/"
in the Node.js command prompt on developing boxes
I've also noticed that Jenkins has a node.js plugin where you are capable of running scripts in a build step. I don't believe I can use the commands npm install -g coffee-script or coffee --compile through node.js scripts rather then the command line. Though I hope I am wrong.
Currently the best option I see is to install node.js on the box, use npm to install coffee script, and then run batch scripts as a build step. Though I am willing to pursue this, I would like less manual installation on the box, to ease the use of coffee-script in more projects.
Is this my best option?
Worth saying though I use node.js to compile coffee-script, node.js itself, and its capabilities, are very new to me.
One possible solution is to run the compiler with the script provided in extras/coffee-script.js. You have to use JDK 7 or the latest Rhino (JDK 6 will not work). Here is a link to a simple CoffeeScript compiler in Java
i would recommend
a) installing nodejs plugin + grunt on jenkins -> Jenkins integration with Grunt
b) voting up the excellent instructions :)
c) then using grunt to compile the coffee script, this also means you can easily locally compile coffee script too!!
grunt instructions -> http://gruntjs.com/
grunt coffee script instructions -> https://github.com/gruntjs/grunt-contrib-coffee
basically you need a Gruntfile.js a bit like this
module.exports = function(grunt) {
// Project configuration.
grunt.initConfig({
pkg : grunt.file.readJSON('package.json'),
coffee: {
compile: {
files: {
'path/to/result.js': 'path/to/source.coffee', // 1:1 compile
'path/to/another.js': ['path/to/sources/*.coffee', 'path/to/more/*.coffee'] // compile and concat into single file
}
}
}
});
grunt.loadNpmTasks('grunt-contrib-coffee');
grunt.registerTask('default', ['grunt-contrib-coffee']);
};
then for the jenkins shell task you just need this, to run grunt and hence coffee script
npm update
grunt