GoogleChromeLabs / tooling.report

tooling.report a quick way to determine the best build tool for your next web project, or if tooling migration is worth it, or how to adopt a tool's best practice into your existing configuration and code base.
https://tooling.report
Apache License 2.0
848 stars 49 forks source link

Proposal: Use always the same test Projects #358

Closed frank-dspeed closed 4 years ago

frank-dspeed commented 4 years ago

I have now worked with this a bit and spotted that all tests use individual projects. When this would get refactored to use only one version of the project for the test we can reduce maintenance and ease of adding new bundlers and tests.

i found out that there are always es6 tests which use import and es5 node require tests for browserify

so i propose to use this with browserify and then only use the es6 src of the test. It transpils ES6 to ES5 for browserify.

import gulp from 'gulp';
import babelify from ‘babelify’;
import browserify from 'browserify';
import source from 'vinyl-source-stream';
import buffer from 'vinyl-buffer';
gulp.task('scripts', () => {
  browserify(['myEntryPoint.js', 'myModule.js'])
  .transform(babelify)
  .bundle()
  .pipe(source('bundle.js')
  .pipe(gulp.dest('dist/scripts'))
  .pipe(buffer())     // You need this if you want to continue using the stream with other plugins
});

This will allow us to change the structure to /tests/test-name/subtests/sub-name/src /tests/test-name/subtests/sub-name/bundler-name /tests/test-name/subtests/sub-name/other-bundler-name

then all bundlers can use the same src.

jakearchibald commented 4 years ago

I have now worked with this a bit and spotted that all tests use individual projects

This is kinda deliberate. If something is testing code splitting, it's ok to use commonjs for browserify but esm for the other tools. If we made it all esm, then you have to add stuff to the browserify example that isn't relevant to the thing being tested. If we make it all commonjs, then you have to add stuff to the Rollup example that isn't relevant to the thing being tested.

I guess at some point we could look at avoid the duplication for cases where it doesn't differ.

frank-dspeed commented 4 years ago

@jakearchibald then at last lets reduce to make eacht test as es6 and es5 version and show in the examples what to do with es6 and what to do with es5.

so that each test runs both an es6 version and an es5 version the user will have mixed module formats most time anyway even with browserify.

so not 1 test project for each bundler we go for 2 test projects for every test

jakearchibald commented 4 years ago

I don't think it makes sense to have an es6 version and an es5 version for every test, unless that's what's being tested.

frank-dspeed commented 4 years ago

@jakearchibald maybe your right and I overengineer it I tend to such failures. Sorry about that.

jakearchibald commented 4 years ago

I think there's merit in joining the source files together in cases where they are the same, but I'm kinda happy right now that each test is sandboxed. There might be a way to achieve both.