Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"TypeError: gen.next is not a function" - Metalsmith 2.5.0 #374

Labels

Comments

@exortech
Copy link

Description
After upgrading to Metalsmith 2.5.0, we're now getting the error:

TypeError: gen.next is not a function

When metalsmith-watch is triggered in response to a file change.

Environment

  • OS (run node -e "console.log(process.platform)"): MacOS
  • Node|npm version (run node -v && npm -v): v16.15.0
    8.5.5
  • Metalsmith version: (run npm view metalsmith version): 2.5.0

Reproducing the bug

Further debugging to follow.

@exortech
Copy link
Author

Ok, it looks like the issue is that metalsmith-watch expects that metalsmith.read is a coroutine. Changing the method signature to return promises breaks the implementation for this plugin. As per the change in this commit: 16a91c5

@webketje
Copy link
Member

webketje commented Jun 14, 2022

Metalsmith < 2.5.0 generator functions were already not intended to be called with unyield in client-code (they could be called just like regular callbacks), so this would be an issue with metalsmith-watch. Metalsmith is not going back to generators, but if you would really like to keep using ms-watch (that I understand in the absence of another alternative), you could fork it and npm i github:exortech/metalsmith-watch, it's a 1-line change (line 179 in addition to removing the unyield dependency) from

unyield(metalsmith.read())((err, files) => { ... }

to (this was how metalsmith-watch should've always used it)

metalsmith.read((err, files) => { ... }

or

metalsmith.read()
  .then((files) => { ... })
  .catch(err => { ... })

As mentioned in the GH team I'm currently considering alternative watch implementations (in priority this is right behind a static method and a good js bundler plugin)

@exortech
Copy link
Author

exortech commented Jun 14, 2022 via email

@webketje
Copy link
Member

Regardless of whether it's an intended use of the method or not, the generator function was exposed in the interface.

I know, for new "private" members I took care to use non-enumerable, unexported JS symbols and marked several as @package, as well as omitted them from the official API docs (readFile, read, write, writeFile) because users/ plugin authors shouldn't rely on them or be prepared to do frequent updates.

[...] which is not something that would normally be done in a minor release

I adhere to semver as much as possible, but there are 2 notable exceptions (which, as you say, would be better to document):

  • I did drop major Node version support for EOL versions in minor releases (normally dropping a major Node version regardless of its maintenance status is a major version change).
  • If a change represents a major improvement that is backwards-compatible with 99% of use cases in plugins that have been updated at least once in the past 5 years, I will consider it eligible for inclusion in a minor release (as I did now).

Plugin registry now includes a notice to discourage users from using severely outdated plugins (no updates in > 5 years).

I will close this issue after adding retroactively, as you suggested, an entry to the changelog, and perhaps an extra note in the plugin registry for metalsmith-watch.

@exortech
Copy link
Author

exortech commented Jun 14, 2022 via email

@webketje webketje mentioned this issue Jun 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment