Bump version to 1.0.0 following 1 year of changes

[tomap]

to show that it is stable

[yoshinorin]

+1

But, IMHO a package version up should just before publish.
I don't know package release plan of hexo. So, I can't judge update this package version or not.

[tomap]

Before we do that, I'm wondering if this file
highlight_alias.json
should not be published?
see the package.json:

    "build:highlight": "node scripts/build_highlight_alias.js > highlight_alias.json",

It was published in the previous version

[tomap]

https://www.npmjs.com/package/hexo-util/v/1.0.0-rc1
(but including the json)

[yoshinorin]

I and @segayuu want to include #58 to new version of hexo-util.
Would you give us time?

[curbengh]

Before we do that, I'm wondering if this file
highlight_alias.json
should not be published?

I think the purpose of not publishing it, instead it is dynamically generated is because new version highlight.js might support new languages. Meaning it is possible that highlight.js supports more than the published version highlight_alias.json.

[tomap]

I think the purpose of not publishing it, instead it is dynamically generated is because new version highlight.js might support new languages. Meaning it is possible that highlight.js supports more than the published version highlight_alias.json.

Ok, if you're sure, I'll publish next RC without it

[curbengh]

highlight_alias.json is not generated when I

"hexo-util": "hexojs/hexo-util",

publish next RC without it, I'll test it.

[tomap]

I just published RC2
Notice that I dropped the useless changelog.md
and ignored *.tgz

@curbengh I published without highlight_alias.json.

[coveralls]

Coverage remained the same at 95.214% when pulling 05bb2d4 on tomap:bump-version into d63fda6 on hexojs:master.

[curbengh]

Did you include #67 in RC2?
How did the *.tgz get there?
I think it's fine to publish changelog, even though it's hardly useful in the current state.

Update hexojs/hexo#3646 to include RC2 too.

[curbengh]

Before we do that, I'm wondering if this file
highlight_alias.json
should not be published?

I think the purpose of not publishing it, instead it is dynamically generated is because new version highlight.js might support new languages. Meaning it is possible that highlight.js supports more than the published version highlight_alias.json.

I just found out the statement is actually outdated. The postinstall step has been replaced by #28 so the build runs during npm publish, not npm install (unless it is executed in ./node_modules/hexo-util).

highlight_alias.json indeed needs to be published, but still remain gitignored.

---

If I

"hexo-util": "hexojs/hexo-util"

somehow it works, despite there is no highlight_alias.json in the repo. The highlight_alias.json does get generated in ./node_modules/hexo-utl.

My guess is highlight_alias.json is generated on client machine when installed from a git repo, but not generated when installed from npmjs.com.

I'll have more testing on RC2 to confirm this.

---

PR fix #69

[tomap]

I just published RC3: https://www.npmjs.com/package/hexo-util/v/1.0.0-rc3

The tgz comes from my way of creating the npm package:

// to check the content
npm publish --dry-run
// to produce the package as a .tgz
npm pack
// to publish the package 
npm publish hexo-util-1.0.0-rc3.tgz -tag next

[curbengh]

I see, I usually just

npm publish --dry-run
npm publish -tag next

[tomap]

I dropped the *.tgz from gitignore and will use your command lines

[tomap]

hexojs/hexo#3646 => tests look good
Shall I merge this PR & publish the new version (stable) ?

[curbengh]

versioning

[JLHwung]

I think we should use npm version instead of pull requests to manually bump the versions.

[curbengh]

I think we should use npm version instead of pull requests to manually bump the versions.

We create PR to notify team members.
https://github.com/orgs/hexojs/teams/core/discussions/5

[tomap]

v1 published
https://www.npmjs.com/package/hexo-util/v/1.0.0
Please merge :)