Skip to content

Commit

Permalink
docs: split off a CONTRIBUTING.md from the README
Browse files Browse the repository at this point in the history
- condenses the README a bit and uses the standard CONTRIBUTING.md file
  - it's a file I often look for when filing an issue or creating a PR
  - leaves the section still in the README so that users (esp. on NPM)
    will know to go there if they're not aware of that convention

- GitHub also now tells users to read the CONTRIBUTING.md of a repo when
  filing issues or creating PRs, so hopefully this helps point more
  users in the right direction as well
  • Loading branch information
agilgur5 committed May 1, 2022
1 parent 4a69b0d commit b8410af
Show file tree
Hide file tree
Showing 2 changed files with 33 additions and 28 deletions.
31 changes: 31 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Contributing

## Reporting bugs

Report any bugs on github: <https://github.com/ezolenko/rollup-plugin-typescript2/issues>.

Attach your `tsconfig.json`, `package.json` (for versions of dependencies), rollup script and anything else that could influence module resolution, ambient types and typescript compilation.

Check if problem is reproducible after running `npm prune` to clear any rogue types from npm_modules (by default typescript grabs all ambient types).

Check if you get the same problem with `clean` option set to true (might indicate a bug in the cache).

If makes sense, check if running `tsc` directly produces similar results.

Attach plugin output with `verbosity` option set to 3 (this will list all files being transpiled and their imports).

## Developing

Use the normal github process of forking, making a branch and creating a PR when ready. Fix all linting problems (run `npm lint`), fix any failed checks that are run on the PR (basically lint right now). Use an editor that supports editorconfig, or match the settings from `.editorconfig` file manually.

Fastest way to test changes is to do a self build, the plugin is part of its own build system:
- make changes
- run `npm build` (uses last released version on npm)
- check that you get expected changes in `dist`
- run `npm build-self` (uses fresh local build)
- check `dist` for the expected changes
- run `npm build-self` _again_ to make sure plugin built by new version can still build itself

If `build-self` breaks at some point, fix the problem and restart from `build` step (a known good copy).

This repo badly needs unittests and integration tests with various scenarios and expected outcomes though.
30 changes: 2 additions & 28 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -213,32 +213,6 @@ TypeScript `2.4+`
Rollup `1.26.3+`
Node `6.4.0+` (basic es6 support)

### Reporting bugs
### Reporting bugs and Contributing

Report any bugs on github: <https://github.com/ezolenko/rollup-plugin-typescript2/issues>.

Attach your `tsconfig.json`, `package.json` (for versions of dependencies), rollup script and anything else that could influence module resolution, ambient types and typescript compilation.

Check if problem is reproducible after running `npm prune` to clear any rogue types from npm_modules (by default typescript grabs all ambient types).

Check if you get the same problem with `clean` option set to true (might indicate a bug in the cache).

If makes sense, check if running `tsc` directly produces similar results.

Attach plugin output with `verbosity` option set to 3 (this will list all files being transpiled and their imports).

### Contributing

Use the normal github process of forking, making a branch and creating a PR when ready. Fix all linting problems (run `npm lint`), fix any failed checks that are run on the PR (basically lint right now). Use an editor that supports editorconfig, or match the settings from `.editorconfig` file manually.

Fastest way to test changes is to do a self build, the plugin is part of its own build system:
- make changes
- run `npm build` (uses last released version on npm)
- check that you get expected changes in `dist`
- run `npm build-self` (uses fresh local build)
- check `dist` for the expected changes
- run `npm build-self` _again_ to make sure plugin built by new version can still build itself

If `build-self` breaks at some point, fix the problem and restart from `build` step (a known good copy).

This repo badly needs unittests and integration tests with various scenarios and expected outcomes though.
See [CONTRIBUTING.md](./CONTRIBUTING.md)

0 comments on commit b8410af

Please sign in to comment.