@rollup/plugin-multi-entry broken by #54

[jlmakes]

@rollup/plugin-multi-entry broken by #54

[Lalem001]

Yes it looks correct, and it works for me locally.

[jlmakes]

Can you share a little more about how it breaks?

I'm curious what @rollup/plugin-multi-entry does to the facadeModuleId, I wasn't able to figure that out by looking at its source.

[Lalem001]

@rollup/plugin-multi-entry registers all the files that it processes under a virtual file with the name of \0rollup:plugin-multi-entry:entry-point. facadeModuleId was the only ID property I could find that maintains the null byte. The rest of the properties like fileName replace the null byte with an underscore.

However, I am just discovering that karma itself prevents @rollup/plugin-multi-entry from working as expected in a different way. The plugin is expecting a glob, but Karma is already expanding the glob to individual files. This observation appears to tread on #49.

Still, that doesn't change the fact that tests were passing with karma-rollup-preprocessor 7.0.0, and failing with 7.0.1 with the same rollup config.

Sorry for being brief, I am in a hurry atm. Can expand more later if still needed.

[jlmakes]

Just following up on this @Lalem001. I'd like to fix this, do you still think your suggestion !hasNullByte() is the best way forward?

[Lalem001]

The suggestion is a possible solution. Karma would never use that particular plugin correctly anyway, since it only sends Rollup (and the preprocessor) 1 file at a time. The solution might resolve problems with other plugins that have not yet been reported.

I will say however that this issue so far has been preventing me from being on latest karma-rollup-preprocessor, and the solution proposed does resolve the issue for me locally.

[jlmakes]

That makes sense. Well, it seems like a fair precaution to check for null bytes. I updated the development branch, does this look correct to you?