Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement threads.js and parcel-bundler #131

Merged
merged 25 commits into from Mar 25, 2020

Conversation

PacoDu
Copy link
Contributor

@PacoDu PacoDu commented Mar 9, 2020

This one is quite a long shot, I've implemented thread.js for the decoder.worker.js (#115) which was the main issue about the package bundling (and babel configuration). I also changed the package bundler to parcel-bundler which is much faster and simpler in my opinion.

Bundle size comparison:

  • Browser:
    • before: 690KB
    • after: 316KB
  • Node:
    • before: 690KB
    • after: 55.13KB

Fixes #53
Fixes #71 by adding set -e to setup_data.sh to force script failure
Closes #115

@constantinius
Copy link
Member

@PacoDu

Wow, that is quite a PR! Thank you very much for providing this. I quickly skimmed over the changes and think it is very sound, although I'm no expert in many cases.

I will do a more detailed review this week (will be mostly further questions), and try to merge this as soon as possible.

Thank you very much (again) for the effort!

@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 10, 2020

Thanks ;)
Some notes about the PR:

  • I wasn't able to determine test/lzw.html purpose, it's not related to any existing source code for the imports. It's commented out for now has it blocks parcel dev server otherwise
  • Threads.js is not working in mocha test so the worker test i wrote is not executed. I couldn't find why but the Pool is properly working once built

@constantinius
Copy link
Member

  • I wasn't able to determine test/lzw.html purpose, it's not related to any existing source code for the imports. It's commented out for now has it blocks parcel dev server otherwise

Thats fair. LZW was developed as a PR, the developer added that html file. I don't think it is necessary to keep it, LZW is tested elsewhere.

  • Threads.js is not working in mocha test so the worker test i wrote is not executed. I couldn't find why but the Pool is properly working once built

Okay. Having a clean build for node, browser and testing was always more of a chore than it should be. Especially when using threads/workers. Maybe there is some way to test that integrates parcel?

@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 12, 2020

I'm not sure about what you mean by

Maybe there is some way to test that integrates parcel?

Parcel is only a bundler and is not related to tests

@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 12, 2020

I took a look about refactoring geotiff.js to native ES6 module in order to be able to load geotiff.js from source in node > 13.2. Currently OSS community seems to be working on upgrading tools and libraries for node native ESM but it doesn't seem quite ready yet. For example thread.js is currently not working with the native ESM module loader of node.js (see andywer/threads.js#220), and it's only one of the issues I encountered will trying to upgrade geotiff.js to native es6 module. That was my first attempt to write ESM modules in node.js but I think I'll wait a bit before retrying, I'll stick to CommonJS for now 😅

Copy link
Member

@constantinius constantinius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are just some minor issues (styling mostly), apart from that I really like the work that has been done here.

Some additional questions would be good to have an answer for:

  • How does the bundling work where geotiff.js is a dependency, such as the COG-explorer? Does it re-bundle the bundled version of geotiff.js? How would tree-shaking work? Is it still possible to import the source itself?
  • Just recently added was the analyzer of the webpack bundle. This of course would be removed. Is there perhaps an alternative for that?

.eslintrc.js Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
src/compression/jpeg.js Show resolved Hide resolved
src/decoder.worker.js Outdated Show resolved Hide resolved
src/pool.js Show resolved Hide resolved
src/predictor.js Outdated
@@ -53,8 +53,7 @@ export function applyPredictor(block, predictor, width, height, bitsPerSample,

for (let i = 0; i < height; ++i) {
// Last strip will be truncated if height % stripHeight != 0
if (i * stride * width * bytesPerSample >= block.byteLength)
break;
if (i * stride * width * bytesPerSample >= block.byteLength) break;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer this form:

if (i * stride * width * bytesPerSample >= block.byteLength) {
    break;
}

Copy link
Contributor Author

@PacoDu PacoDu Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eslint rules related. We should either change the rule, add curly braces or use the inline syntax.
https://eslint.org/docs/rules/curly

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks. I would prefer to use the all rule here. Do you want to add this to your PR since you're already at it? Otherwise, we can do this separately as-well.

test/data/.gitignore Show resolved Hide resolved
test/dev.js Show resolved Hide resolved
test/lzw.html Outdated Show resolved Hide resolved
@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 14, 2020

Just recently added was the analyzer of the webpack bundle. This of course would be removed. Is there perhaps an alternative for that?

I've added the equivalent for parcel ;). The only difference is that it generates the report at the build step, and in the corresponding dist folder.

How does the bundling work where geotiff.js is a dependency, such as the COG-explorer? Does it re-bundle the bundled version of geotiff.js? How would tree-shaking work? Is it still possible to import the source itself?

This depends mostly on the main project configuration. Current sources are unusable without a transpiler because it's not pure ESM. In most cases the main project will import the bundled version, and will target the desired bundle depending on it's configuration by following the main or browser variable of package.json

"main": "dist-node/main.js",
"browser": "dist-browser/main.js",

Sources can only be imported if the main project uses a module loader like babel or esm.

About tree-shaking, it will probably depends on the tree-shaking implementation, but I don't see why it wouldn't work, I'll do some tests to confirm.
If you talk about tree-shaking for geotiff.js, I wanted to enable it but I'm facing an export/import error with threads.js. I'll try to investigate as I think we can still significantly reduce the bundle size with tree-shaking (called scope-hoisting in parcel).

@constantinius
Copy link
Member

I've added the equivalent for parcel ;). The only difference is that it generates the report at the build step, and in the corresponding dist folder.

Awesome, I like that even better.

Current sources are unusable without a transpiler because it's not pure ESM.

Hm, why not? And how could we translate the codebase to pure ESM?

About tree-shaking, it will probably depends on the tree-shaking implementation, but I don't see why it wouldn't work, I'll do some tests to confirm.
If you talk about tree-shaking for geotiff.js, I wanted to enable it but I'm facing an export/import error with threads.js. I'll try to investigate as I think we can still significantly reduce the bundle size with tree-shaking (called scope-hoisting in parcel).

I've seen the issue, thanks for investigating and raising this issue.

Thank you for providing all the clarifications! I think this is almost ready to be merged (see last items above), if you are of the same opinion.

@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 17, 2020

I'll do some adjustment for eslint rules (curly), one last review of the changes and I think we are good to go !

@constantinius
Copy link
Member

@PacoDu from my point of view this looks very good. If you agree, we could merge this PR now.

@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 25, 2020

Sorry for the delays, I think we are good to go.
Maybe more tests on browsers would be great (I've only tested chrome).

About pure ESM I'll try to take some time to answer but, for what I've experienced while trying to upgrade geotiff.js to pure ESM, this is quite a complicated subject.

@constantinius
Copy link
Member

Alright, I think we can stick with what we've got.
Thanks again for your contribution! :-)

@constantinius constantinius merged commit d3b0958 into geotiffjs:master Mar 25, 2020
@PacoDu
Copy link
Contributor Author

PacoDu commented Mar 25, 2020

Can you make a version bump and publish the package ?
What is the roadmap for 1.0.0 ?

Thanks !

@constantinius
Copy link
Member

Sure, will do.

What is the roadmap for 1.0.0 ?

Hm, undefined. There are some functionalities that would be really nice like #94, and #135. Also #139 points to a bug on node.

I think I'll make an official roadmap for v1.0.0 using the github project feature.

@constantinius
Copy link
Member

new version is published (and automatic building too)
Project is up https://github.com/geotiffjs/geotiff.js/projects/1

@constantinius
Copy link
Member

@PacoDu I think something is missing for building: https://travis-ci.org/github/geotiffjs/geotiff.js/builds/671327370#L1405
Travis CI deploy fails, as it seems that it cannot build the final package for upload.

Do you have an idea?

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! geotiff@1.0.0-beta.9 build:browser: `parcel build src/main.js --target browser --out-dir dist-browser/ --global GeoTIFF`
npm ERR! spawn ENOENT

Travis is failing because it's using node v9.11.2 and threads.js requires tiny-worker to work for node <12 (see: https://threads.js.org/getting-started#installation).

We should upgrade node version for Travis CI or decide to support node <12 and add tiny-worker as a dependency.

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

I may have misunderstood the error here, I don't see why this is related to the build command ...
I'll take a closer look tomorrow

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

Well, that's not related to threads.js, I was misled by https://travis-ci.org/github/geotiffjs/geotiff.js/jobs/671327371#L1292 but there is no tests using the worker pool so node 9.11.2 is not an issue for now.

I pulled the 1.0.0-beta.9 tag from scratch and npm run build was successful locally with node 9.11.2 ... I don't understand why this is failing on travis, also the build command is working at the npm install step : https://travis-ci.org/github/geotiffjs/geotiff.js/builds/671327370#L568

... Could we try to retrigger the CI ?

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

I never used travis but I think I've found the issue here:
I see a skip_cleanup: true used for the deploy:pages step:
v1.0.0-beta.8...v1.0.0-beta.9#diff-354f30a63fb0907d4ad57269548329e3R30

Wouldn't it be required for the deploy step to keep node_modules directory ? It seems like node_modules disappeared between the tests and the deploy stage, because the build command is working after npm install (https://travis-ci.org/github/geotiffjs/geotiff.js/builds/671327370#L568) and failing at npm prepare (https://travis-ci.org/github/geotiffjs/geotiff.js/builds/671327370#L1405)

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

I think we could jump to node 12 instead of node 10 (to avoid tiny-worker dependency) as it's about to leave LTS in a month: https://github.com/nodejs/Release#release-schedule. Or we could just add a note in the readme for node <12 to install tiny-worker as a dependency if they want to use Pool.

@constantinius
Copy link
Member

Hrm, I actually set the node version to 12 in the latest build (typo in commit message says v10) but it apparently ran into issues:
https://travis-ci.org/github/geotiffjs/geotiff.js/builds/671558364#L539

I think it is fair to stick to v12.

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

This should be solved now that you rebuilt the package-lock.json in your latest commit.

I recommend using npm version to upgrade the package version (it automatically set package.json and package-lock.json values), but maybe you are already using it :p

@constantinius
Copy link
Member

I recommend using npm version to upgrade the package version (it automatically set package.json and package-lock.json values), but maybe you are already using it :p

I do :-)

Welp, apparently travis insists on re-building node v12 every time a test is triggered, thus resulting in a build time timeout. This does not behave correctly, right?

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 6, 2020

This occurs when the pre-built binary is not available. For travis CI setting the version to lts or 13 should do the trick to find a pre-built version. It doesn't matter if node 13 is used to build the package. And we should increase engines.nodes to >=12 in the package.json

@constantinius
Copy link
Member

Okay, I think the build and deploy now work.

I think that the documentation was broken at some point, and it may be during this PR. (https://geotiffjs.github.io/geotiff.js/index.html)

But I think it needs an overhaul anyways.

@PacoDu
Copy link
Contributor Author

PacoDu commented Apr 7, 2020

Oh, sorry for the trouble, what was broken ?

@constantinius
Copy link
Member

I'm not sure when it happened, but the whole API reference is pretty broken and unusable. I'll try to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate threads.js ENOENT Error when try to run npm test Running without babel
2 participants