This is useful for bundlers. When dealing with reexports, this setting
allows e.g. webpack to optimize reexports. See the webpack documentation
for more information about this setting
The hero module is very specific and not really a good fit for a low
level library like snabbdom. Users that still want to use it can copy
the code from the hero example instead
ISSUES CLOSED: #517
BREAKING CHANGE:
Snabbdom does not export the hero module any more. If you require this
module, copy the code from examples/hero/hero.js and add it to your
project
3 tests are still failing for safari 9.1 at the moment. On safari 10.1
all the tests pass however. As El Captain is pretty old now, the tests
now run on Sierra. The current safari version is updated to 14
ISSUES CLOSED: #469
Chrome 49 was disabled in the browserstack tests because of failing
tests. Trying those tests now again, only a single CSS variable test is
failing. As chrome 49 was the first chrome version to support css
variables it is very likely that this is a bug in the browser itself,
especially as chrome 50 works as expected. Thus this commits enables the
browserstack tests for chrome 50
ISSUES CLOSED: #468
Currently even IE11 is marked as End-Of-Life (EOL), IE10 is even
longer. Karma internally uses `Object.setPrototypeOf` which is not
supported in IE10. Rather than trying to polyfill this, we should only
test IE11 and MS Edge
When removing unnecessary dependencies, polyfills like core-js were
removed, as well as webpack which bundled the tests to es5. With this
commit, tests that need specific browser features are skipped if the
browser does not support them and the code is compiled to es5 by
karma-typescript
The environment was used to ensure that the browserstack access keys
are only available after approval, so a potentially malicious actor
can't modify the testing code and extract those secrets. This however
creates a lot of noise in the notifications of the maintainers and it
drastically reduces the feedback cycle for the contributor in case their
change causes an issue in one of the supported browsers. Additionally
the potential harm in extracting the access keys is pretty low. The
snabbdombot account has only user access, so it can't change
browserstack settings and it can only access the automate features. So
the only thing that can happen is that our PRs fail because some third
party is running browser tests and thus exhausting our 5 parallel tests
limit. In that case we can simply change the access key of the
snabbdombot account. For this reason, the secrets are now repository
secrets and the CI does not need an approval to run
release-it automates all the steps defined in CONTRIBUTING.md. In
addition to that it can also create GitHub releases with the relevant
part of the CHANGELOG
Now that we use prettier, we can automatically format the README
anyways. The only difference then would be the automatic table of
contents, but the structure of the README does not change often and is
not very complex, so there is not really a need to automate this
This puts the fields a user of snabbdom would be interested in at the
very top (including stuff like license information, homepage etc). After
that come the fields interesting to a snabbdom developer like scripts
and devDependencies. Lastly is the configuration for dev tooling
commitlint can't provide the user with a convenient prompt to create a
fitting commit message, while commitizen is not able to lint an existing
commit message. The newly released commithelper does both
ISSUES CLOSED: #913, #748
BREAKING CHANGE:
The imports of snabbdom functions have changed. Every file in the
project had to be imported on its own, e.g.
```
import { h } from 'snabbdom/h'
import { VNode } from 'snabbdom/vnode'
```
Now, the main snabbdom package exports all of the public API like
```
import { h, VNode } from 'snabbdom'
```
This means consumers of the snabbdom package need to update their
imports. The change makes the use of the `exports` field in
`package.json` unnecessary, which caused issues for TypeScript users