Closed sheerun closed 8 years ago
I fixed this in the commit above so it no longer errors without these.
Even if these aren't in your package.json, it might still be important to use them with hjs-webpack
since they are used to build filenames when in production mode. To bypass this, pass hjs-webpack
a package
object with a name
and version
. Here's an example:
const getConfig = require('hjs-webpack')
module.exports = getConfig({
package: { name: 'some-name', version: '0.0.0' }
// ...other options
})
Would this have been a breaking change if you are using a custom conifg with getConfig
? After upgrading, my files are names built-by-hjs-webpack.0.0.0
by default, and I had to require the package.json
file and pass it along manually to get them back to what they were before. Not sure if this was expected or not.
@kennethormandy Shoot, that wasn't intended, but I see what you're saying. I'll try to get a patch out tomorrow that returns it to the previous behavior, but still doesn't error if you don't have a name/version.
@kennethormandy I reverted the previous change, and reimplemented only to avoid throwing an error in the valid case stated by the OP. This should allow you to no longer require your own package.json and pass it along with the rest of the config. Sorry for the trouble!
@lukekarrys Hey, thanks so much, that was quick! It was barely any trouble, just wanted to see if it was expected. The work you and @HenrikJoreteg have done on this project is amazing, it’s been really, really helpful for me.
What happens:
I have a private package without name and version (accepted by npm). When I run hjs-webpack I get error when any of these fields is missing, though.
What should happen:
I should be able to use hjs-webpack with private packages without name and version.