fix: upgrades our dependencies

atom / highlights

Syntax highlighter

https://atom.github.io/highlights

MIT License

530 stars 54 forks source link

fix: upgrades our dependencies #42

Closed bcoe closed 7 years ago

bcoe commented 8 years ago

notes

updating the coffee-script linter required a few stylistic nits, if folks could make sure I didn't typo anything.
I switched us from optimist to yargs (which meant I could remove a few lines of code).
I added standard-version, which I can use shortly to manage our semver bumps and CHANGELOG generation, see: https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md

bcoe commented 8 years ago

reviewers: @ashleygwilliams, @revin, @kevinsawicki

bcoe commented 8 years ago

@ashleygwilliams @revin I've published a candidate release of this branch, which includes the updated atom-language-javascript mind giving it a spin with marky-markdown?

npm cache clear; npm i highlights@next

revin commented 8 years ago

Thanks so much for doing this, @bcoe!

Is there any documentation anywhere that you know of describing the changes? The marky unit tests aren't exhaustive when it comes to checking the minutiae of the generated markup, so all I can tell is there is at least one class (modifier) that isn't showing up anymore in our tests, and there are a handful of additions (function-call, different logic around when meta gets applied, etc...) and tweaks to the output. I'm asking because it'd be nice to be able to put some specifics in our release notes if we could (the most visible consumer of this is surely going to be the npmjs.com site, so they'll probably be on the hook for CSS updates), and I don't really trust myself to reverse engineer it sufficiently by running lots of code through it :smile:

/cc @ashleygwilliams

revin commented 8 years ago

Heh, I guess there's always the diff: https://github.com/atom/language-javascript/compare/b47a7fe...5fb7053

bcoe commented 8 years ago

I made a point of picking a specific release tag of atom-language-javascript, I think this is probably the safest approach (rather than picking whatever sha master happens to be at a given time) -- unfortunately, if there's not a CHANGELOG for the project, I think pulling the commit history is your best bet.

On a more meta level of conversation, better change tracking is why I've been championing the standard-version library. This encourages folks to write commit messages in a format that can auto-generate a CHANGELOG, providing better forensic information for situations like this one.

How have things been working for you with the next version of highlights? do you have a way to test what rendering will look like?

revin commented 8 years ago

It works fine for me from here if I change the one failing test to match the new output; other than that, marky's not really concerned with styling, so from a markup generation perspective, we're good to go; it's on consumers of marky's output to update their CSS and make things look nice 😄 😦

bcoe commented 8 years ago

@revin as another smoke test, we'd probably be smart to get @ashleygwilliams to test some of the new rendering in the npm website, before we call this shippable.

I believe here and @soldair have a tool that can test rendering against all of npm's README.md files, great smoke test.

zeke commented 8 years ago

https://github.com/npm/readme-tester

ashleygwilliams commented 7 years ago

hey ya'll! somehow missed the ping, am testing now

bcoe commented 7 years ago

@revin @ashleygwilliams published in + highlights@1.4.0.

ashleygwilliams commented 7 years ago

told @bcoe yesterday that the tests went fine- should be all set.