To E2E test this, for basic developer confidence, one could just create a basic JS project that's built with webpack, and has test coverage. Then, just write some tests for that demo project, demonstrating that requires now enforce case-sensitivity. In my case, I had to add the plugin to plugins on not only my webpack.config.js but also to the webpack config in my karma.conf.js.
Then, I created a jasmine spec file similar to the following:
describe("Case-Sensitive Paths Plugin", () => {
it('shouldn\'t interfere with correctly-spelled imports', () => {
const demoImport1 = require('../src/utils/api');
expect(demoImport1).toBeDefined();
});
it('should cause mistakes in filename case to fail import', () => {
expect(() => {const demoImport2 = require('../src/utils/API');}).toThrow();
});
it('should cause mistakes in path case to fail import', () => {
expect(() => {const demoImport3 = require('../src/Utils/api');}).toThrow();
});
});
Then I just run my standard unit-tests for the project. If the plugin is active, the last two tests pass, and if I disable it, they fail.
This is by no means an elegant solution that'll help you with ongoing development. But it gives me as an end-user some confidence that the plugin does what it says on the tin.
To E2E test this, for basic developer confidence, one could just create a basic JS project that's built with webpack, and has test coverage. Then, just write some tests for that demo project, demonstrating that
require
s now enforce case-sensitivity. In my case, I had to add the plugin toplugins
on not only my webpack.config.js but also to the webpack config in my karma.conf.js.Then, I created a jasmine spec file similar to the following:
Then I just run my standard unit-tests for the project. If the plugin is active, the last two tests pass, and if I disable it, they fail.
This is by no means an elegant solution that'll help you with ongoing development. But it gives me as an end-user some confidence that the plugin does what it says on the tin.