Still using deprecated rollup option key about karma-rollup-preprocessor HOT 8 CLOSED

It’s a little awkward maintaining a package > 1.0.0 that relies on a package < 1.0.0.

I’m not sure I see a path that doesn’t involve a breaking change in the preprocessor... and changing to a peer dependency does sound like a good idea.

So what about a preprocessor bump to 4.0.4 with 0.45 <= rollup < 0.48 to damage control broken legacy configs... and a preprocessor 5.0.0 with peer rollup >= 0.48?

Note: I planned to address #17 as well in the next major bump. I think this will be a good time to try and implement that as well.

from karma-rollup-preprocessor.

So what about a preprocessor bump to 4.0.4 with 0.45 <= rollup < 0.48 to damage control broken legacy configs... and a preprocessor 5.0.0 with peer rollup >= 0.48?

That seems good 👌

from karma-rollup-preprocessor.

Still running into some issues…

from karma-rollup-preprocessor.

@jlmakes What kind of issues? I just checked the master branch on one of my project and it seems good.

from karma-rollup-preprocessor.

• ❌ Rollup 0.48.2 / Legacy Config / Preprocessor 4.0.3

  Unexpected key 'moduleName' found (preprocessor failed)

• ❌ Rollup 0.48.2 / Legacy Config / Preprocessor master

  Unexpected key 'moduleName' found (preprocessor failed)

• ❌ Rollup 0.48.2 / New Config / Preprocessor 4.0.3

  options.entry is deprecated, use options.input (tests failed, no files to test)

• ✅ Rollup 0.48.2 / New Config / Preprocessor master

Contrary to Rich Harris’ tweet suggesting there shouldn’t be much breakage—this doesn’t look very backwards compatible. The complete abandon of semantic versioning for Rollup is frustrating… Rollup 0.45 and 0.48 both slipped in breaking changes.

I’m wondering if preprocessor 4.x should be legacy format (i.e. 0.45 <= rollup < 0.48)
and a new preprocessor 5.x could support the new format (i.e. rollup >= 0.48.0)

Thoughts?

from karma-rollup-preprocessor.

Your errors seems related to the configuration in your project since the preprocessor does not set/get any moduleName option.

I don't think this is the responsibility of the karma-rollup-preprocessor to patch the configuration to the new (or old format) for keys that are not read or set by the preprocessor. Instead each project should use a rollup configuration which is compatible with the version of rollup installed in the project, but maybe I'm wrong.

The complete abandon of semantic versioning for Rollup is frustrating

Well... Until a version 1.0.0 is released, semantic versioning allow breaking changes between versions. But that's frustrating, I agree :)

from karma-rollup-preprocessor.

So, what I’m hearing is that if developers run into errors because the preprocessor installed a different version of Rollup...

It’s up to the developer to update their configuration, not the preprocessor to continue to work with their existing configuration?

from karma-rollup-preprocessor.

@jlmakes Maybe, rollup should be a peer dependencies, not a direct dependency?

Doing this will force developers to choose what version of rollup to install, and so use a configuration compatible with the version that is installed (for example, karma-webpack define webpack as a peer dependency too). That said, doing this will be a breaking change.

from karma-rollup-preprocessor.