Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Migrate from Grunt to npm scripts #584

Merged
merged 16 commits into from
Oct 28, 2018

Conversation

IllusionMH
Copy link
Contributor

@IllusionMH IllusionMH commented Oct 25, 2018

Fixes #484

This PR reimplements current Grunts tasks with npm scripts with only minor changes to code (mostly ES2015 features and lint fixes) without any change of existing logic.

At this point new npm scripts based build should produce identical state of dist folder in comparison with Grunt based build (with exception of updated REAMDE.md, package.json that now contains additional entries in scripts, maps for files with lint fixes, and removed extra line endings in templates)

New benefits:

Things that were "lost" (not re-implemented or there is no clear solution with npm scripts):

  • Total build time and splits by tasks indication
  • --force option to continue even if error happens
  • Colorful output for warnings/errors in custom tasks (validations, generation etc.)
  • Watcher that launches tests and lint after changes (will return soon)

Additional changes are added for Debug tasks for VS Code and instructions on how to debug it in general case.

I'd like to discuss questions about not implemented parts and changes in build steps/logic during chat.

@@ -0,0 +1,141 @@
const path = require('path');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea for better file name. Any suggestion?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about splitting into common/files.js for file IO and common/metadata.js for everything else?

Copy link

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very exciting!

README.md Outdated
The `node-debug` command will load Node Inspector in your default browser (works in Chrome and Opera only).
To debug rules that have Mocha tests use:

node --inspect-brk ./node_modules/mocha/bin/_mocha --no-timeouts --colors "dist/src/tests/**/*.js"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: would you mind using ``` formatting here? GitHub's renderer thinks the _ before `mocha` is an italic block starter.

```shell
node ...
```

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually do this, but decided to follow already used style. Will change.

README.md Outdated

> NOTE: Run `npm test` before `npm start` to copy all required files to `dist` folder.

> NOTE: If breakpoins are not hit you can try to use `inlineSourceMaps` instead of `sourceMaps` in `tsconfig.json`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: breakpoints

@@ -0,0 +1,141 @@
const path = require('path');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about splitting into common/files.js for file IO and common/metadata.js for everything else?

build-tasks/common.js Outdated Show resolved Hide resolved
try {
return fs.readFileSync(String(fileName), {encoding: 'utf8'});
} catch (e) {
console.error(`Unable to read file: ${String(fileName)}. Error code: ${e.code}`);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: is the String(...) necessary? Can we just do Unable to read file: ${fileName}. ...`?

package.json Outdated
"generate:sdl-report": "node build-tasks/generate-sdl-report.js",
"generate:rule-metadata": "node build-tasks/generate-rule-metadata.js",
"generate:package-json-for-npm": "node build-tasks/generate-package-json-for-npm.js",
"create-rule": "node build-tasks/create-rule.js"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind alphabetizing these rules? I always find it really difficult to scan through lists of tasks unless they're grouped nicely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to sort alphabetically by group/single tasks.
But current order inside "group" (e.g. generate:<task>) helps keep test script short enough.
As I've seen - npm-run-all preserves tasks order in case when invoked with as npm-run-all generate:* where order matters. Otherwise full script names should be specified in correct order.

Should I leave order inside group as per execution order (create-rule will be moved up, test & start down etc.) or should I reorder everything and explicitly set order inside test script?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving order inside the groups seems good, thanks!

@@ -0,0 +1,78 @@
const common = require('./common');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const common = require('./common');

I'm not a big fan of import * as exports for collections of miscellaneous functions. It becomes a bit harder to tease them apart & refactor when they're prefixed with a name like that. Let's switch to const { specificOneIWant, otherFunction ] = require('./common');.

@JoshuaKGoldberg JoshuaKGoldberg added the PR: Waiting for Author Changes have been requested that the pull request author should address. label Oct 26, 2018
@IllusionMH
Copy link
Contributor Author

IllusionMH commented Oct 26, 2018

I've fixed all comments and resolved all that we decided to leave as is (exit code, js.lint files).
Removed compilation step for test-data as we discussed earlier.
Colors are back - validation errors have yellow color, other errors that prevent further execution are red.

Code is ready for final review.

As for watch mode - if it is not critical for this PR, I'll make separate PR a bit later.

@JoshuaKGoldberg JoshuaKGoldberg added PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon! and removed PR: Waiting for Author Changes have been requested that the pull request author should address. labels Oct 27, 2018
Copy link

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I'll play with it locally just to be sure...

Copy link

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Played with it locally a bit and couldn't break anything. Thanks so much @IllusionMH! This is a great change and should make development utilities quite a bit smoother. 👏

@JoshuaKGoldberg JoshuaKGoldberg merged commit bf1c20d into microsoft:master Oct 28, 2018
@IllusionMH IllusionMH deleted the grunt-npm-migration-484 branch November 4, 2018 23:30
@JoshuaKGoldberg JoshuaKGoldberg added this to the 6.0.0-beta0 milestone Nov 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replace Grunt dependency with npm scripts
2 participants