We have to remove `--failAfterWarnings` from our Rollup integration-test,
because Typescript, when targeting es5, will use global `this` for transpilation.
Rollup warns about this, since it replaces `this` with `undefined`:
```
src/index.js → dist/bundle.js...
(!) `this` has been rewritten to `undefined`
https://rollupjs.org/guide/en/#error-this-is-undefined
../../../node_modules/@handlebars/parser/dist/esm/printer.js
1: var __spreadArrays = (this && this.__spreadArrays) || function () {}
```
See https://github.com/handlebars-lang/handlebars-parser/releases/tag/v2.0.0
* Updated lock-file to fix https://github.com/npm/cli/issues/4859.
* Updated integration-tests to webpack 5 to fix
https://github.com/webpack/webpack/issues/14532.
* Added `mode` to webpack-integration-tests to avoid
the warning `The 'mode' option has not been set...`.
* Replaced outdated `grunt-bg-shell`-package to get rid of
coffee-script warnings
By adding the `.js`-extension to the bin-file, IDEs will
know that js code-highlighting should be applied to the
file, which makes it easier for devs to read the code.
Extracts the parser to `@handlebars/parser`, where it can be shared
between different implementations. This means that e.g. Glimmer/Ember
will be able to iterate on new features without forcing Handlebars to
adopt them immediately, and vice versa. All implementors will be able to
absorb changes as it makes sense for them.
- move dtslint (checkTypes) away from Gruntfile.js
(as it disturbs debugging `grunt`)
and call it directly as npm-script in travis-ci
- re-group task definition in Gruntfile.js
- use a multi-job travis build to
run linting, format, dtslint and tests
in parallel
- run only "npm test" on appveyor
- rename Grunt-tasks for be more descriptive
- SAUCE_USERNAME is not a secret variable anymore
it can be easily guessed anyway and the
[secure] value messes up with a lot of the
log output
- linting on commit disable during transition
- add prettier to do formatting
- add eslint-config-prettier to
disable rules conflicting with prettier
- remove eslint from grunt workflow
- use lint-stage to lint and format
on precommit
- use eslint and prettier in travis directly
- remove rules that are already part of
the "recommended" ruleset
That rational is that eslint and prettier should be run in
Travis-CI, on commit and as IDE integration (highlighting
errors directlry). They don't need to be run along with
test-cases. Getting linting errors when running the tests
because of missing semicolons is just annoying, but doesn't
help the overall code-quality.
Igor Savin
Jakob Linskeseder
Nils Knappmeier
Chris Garrett
Jordan Mele
Hannah Wolfe
Douglas Christopher Wilson
Nils Knappmeier
Avi Vahl