* docs: split off a CONTRIBUTING.md from the README
- 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
* docs: improve formatting, grammar, and links in CONTRIBUTING.md
- slightly change reference to GH Issue Tracker
- use oxford commas everywhere for clarity
- missing "the" in a few places
- more minor grammatical fixes (missing space, semicolon vs. comma, etc)
- fix: "npm_modules" -> "`node_modules`"
- fix: "npm lint" -> "npm run lint", "npm build" -> "npm run build",
"npm build-self" -> "npm run build-self"
- short-hand works in Yarn and for some pre-defined Node scripts, like
`start` and `test`, but the rest need `run`
- "typescript" -> "TS" (prefer proper "TypeScript" or just "TS")
- use backticks monospace/code formatting where appropriate
- link to GitHub's official docs on forking and making PRs
- also use the word "standard" instead of "normal" as it's more
inclusive and reflective that this is a convention/standard
- link to editorconfig site
- link directly to `.editorconfig` with a relative link as well
- reword portion about PR checks as they do run `build` and `build-self`
nowadays (not sure how old this text is)
- use an ordered list (instead of unordered) for the testing process
as this is meant to be done in order
1.9 KiB
Contributing
Reporting bugs
Report any bugs in the GitHub Issue Tracker.
Attach your tsconfig.json, package.json (for versions of dependencies), rollup.config.js, and anything else that could influence module resolution, ambient types, and TS compilation.
Check if the problem is reproducible after running npm prune to clear any rogue types from node_modules (by default TS 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 it 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 standard GitHub process of forking, making a branch, and creating a PR when ready. Fix all linting problems (npm run lint) and fix any failed checks on the PR. Use an editor that supports editorconfig, or match the settings from .editorconfig 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 run build(uses last released version on npm) - check that you get expected changes in
dist - run
npm run build-self(uses fresh local build) - check
distfor the expected changes - run
npm run build-selfagain 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 the build step (a known good copy).
This repo badly needs unit tests and integration tests with various scenarios and expected outcomes though.