* 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
- this was introduced in v4.1.0 of @rollup/pluginutils:
https://github.com/rollup/plugins/blob/master/packages/pluginutils/CHANGELOG.md#v410
- this is the same as the code in `normalize.ts` but it uses constants
from Node and is used by multiple Rollup plugins, so just helps with
standardization
- also less code and types to ship in the bundle!
- removed the dist files for `normalize` as well, but didn't do a build
in this commit as those are usually done in separate commits
- "latest 2.x" is no longer accurate and quite outdated (we're on 4.x
now), so just say it's the peerDep instead
- @rollup/plugin-typescript calls the default a peerDep too:
https://github.com/rollup/plugins/tree/master/packages/typescript#typescript
- be more specific that you can pass in a different version or fork of
TS (like `ttypescript`) through this option
- follow-up to 8ec49c78f523687deaf6816bc2ea320f16e325c7
- auto-trim some whitespace-only lines
- my editor does this automatically, and most of the README has
trimmed whitespace anyway, so this keeps it consistent
- `rollup-plugin-` -> `@rollup/plugin-`
- just less confusion for newer users who may not be aware of the
previous naming. and up-to-date / current naming anyway
- clarify grammar in `@rollup/plugin-babel` to be a bit more specific
- remove part about what "it claims", no need for negative tone
- add a link to the Babel plugin's docs for its default extensions
- comment out ellipsis in code samples (closer to valid code)
- it had a deprecation warning on install stating that types were
built-in now
- confirmed that my editor picks up the types fine without and that
builds still work
- auto-alphabetize deps
- update package-lock.json version to match package.json version
- NPM did both of these automatically when I ran `npm install`
- fix: missing `#` in `outDir` reference ("83")
- use `org/repo#num` consistently
- previously was `Microsoft/TypeScript/issues/num` or
`rollup/issues/num` inconsistently
- this is how GitHub displays references to other repos in comments as
well, so consistent with the rest of GH too
- links haven't changed, just the text of the them
- auto-trim some whitespace-only lines
- my editor does this automatically, and most of the README has
trimmed whitespace anyway, so this keeps it consistent
- previously it just linked to the image itself; better to link to the
source of the stats which is NPM
- duplicates the other badge's link, but nbd, better than linking to
an image imo
- it's a deep merge that merges them by index
- the rest of the docs are accurate, just this one mention was incorrect
- eventually should move to shallow merge/replace arrays to better
reflect how `tsconfig` `extends` works, but just fix the docs for now
- I originally made the spoilers and while they work (and I would say
improve readability a good bit), there's also some issues with them
- I've used them a ton more now so know how to workaround most
of the issues with them now
- fix: use HTML `code` tag inside of `summary` tag, can't use backticks
- was mixing MD and HTML before, and this doesn't always work and
didn't work on GitHub, they just had backticks
- fix: don't duplicate the file name in the heading, just make the
`summary` have a heading inside it instead
- use an `h4` same as the `####` that it was before
- feat: add syntax highlighting by adding code blocks for each code
snippet
- js for rollup.config.js, json5 for tsconfig (it has comments,
trailing commas, etc (actually a custom parser, but json5 is close
enough)), json for package.json, and text for verbose logs
- also, a lot of people sometimes just paste the code with no code
block and it formats terribly, so this should help defer that
(as well as any potential issues that can crop up with unindented
blocks)
- the `envinfo` text code block seems to be working well, so
hopefully this will improve issues too
On Windows the normalized paths in resolveId end up in POSIX format.
This cause rollup to treat the returned path as a new piece of content.
This in turn results in duplicate output for references across entry points.
Fixed by normalizing the path to use host OS separators before returning.
- long logs of output or long configs are hard on the eyes and make it
difficult to read through issues as they just take up so much space
- so it would be better, in my opinion, to hide them by default with
spoiler tags, which can be opened up when further investigation is
warranted
- some issue authors have already used this pattern, this just brings
it to the template itself so everyone (hopefully) starts using it
- replace the version list with a copy+paste this envinfo command,
copy back the output
- uses a modified, shortened variant of something being used
successfully downstream in TSDX: 349f299976
- this should make reporting versions zero-effort and thereby
significantly decrease non-reporting by making the hard thing easy
- personally have experienced issues that didn't report but version
was very relevant to the issue
- also some folks report "latest" or used carets, which lack posterity
or are confusing
