Sockjs is used for all websocket connections in meteor. It promises to provide a http fallback in cases where native websockets don’t work.
The current sockjs implementation was copy-forked (the library source code was copied into meteor) in 2012 using version 0.3.4 of sockjs and after that the real sockjs library has evolved to version 1.4.0 while the copied code also received changes that were the reason to fork the code way back.
There are known bugs like this one and no one has appeared yet that show a deep understanding of the code and could help fix it.
So I wonder what would be a good way forward. This is such a crucial part of Meteor and also hard to test.
Later, there was a discussion about how the use of dynamic-import forces you to allow the unsafe-eval browser policy, and about being able to remove dynamic-import from meteor apps if you wanted to.
The only core package that required dynamic-import was socket-stream-client for the case where a modern browser failed to connect to a websocket, SockJS would be loaded and used instead.
Because #9985 had made that import static, the dynamic-import was redundant and removed to allow folks to remove dynamic-import and enforce no unsafe-eval
In the end, we’re back where we started, with a copy-forked SockJS 0.3.4 loaded for all browsers
The ideal would be that native sockets are used where possible and fall-back to SockJS’s socket or http polling approach, with SockJS always loaded for legacy browsers
Looking at the errors that caused Ben to import SockJS statically for modern again, I think it was unrelated to SockJS and instead was a bug in dynamic-import not setting the correct url for fetching modules. I recognise that error because we ran into it a bit around that time as well, especially when connecting to another meteor instance across a network.
It might be possible to combine all the past approaches, and use dynamic-import if the package is available, and otherwise using server-render for modern only as a backup?
this topic got me thinking about how important it is that meteor have some people volunteering to maintain all the tests and to help write new test cases. so developers can make changes and feel confident they arent introducing regressive behavior
But in general I feel like alot of effort has been made to cover meteor with automated tests and now that I read through the source in my free time i would like to be in a position to help maintain that test coverage in the future
The implementation for dynamic-import can be found in the meteor repo, and there you can find both the “eval” calls to load a module data into executable code and also the setup where the package adds unsafe eval to the csp statements.
It would be quite tricky to polyfill this, but now that Microsoft is moving Edge to Chromium there is hope for native (modern) support for this feature.
Making it possible to exclude dynamic-import from the ecmascript package would be a start towards being able to provide a custom implementation, eg a polyfill that loads packages from a static location
Meteor is unlikely to use a native implementation as it currently has a lot of extra features to cache modules in indexDB and only fetch exactly the modules missing for that specific client. ie. perfect module splitting
Maybe the WCG will eventually reach feature parity with module-maps, but I don’t think this feature set is in the works yet.
Which is why my suggestion is to add a weak dependency, so it uses it if it’s already installed, and fallback to always loading SockJS when it’s not
Any package, either core, non-core or atmosphere, can be copied into the /packages/ folder of your app and it will use your local version instead. Extremely useful when you just want to make one change to an atmosphere package!
Although, editing in a local clone of the Meteor repo has the advantage of testing against Meteor’s test suite. You can test it with your app by setting the METEOR_PACKAGE_DIRS environment variable to use the packages folder of your Meteor clone
Great - although I was thinking beyond local development. Is there any way to publish a forked version of a core Meteor package and make your builds use it, i.e. a “package override” (with lots of warning messages about how you’re on your own if you do this )?
In my instance, I would want to build a deployable package from my circle-ci build server to test any changes in my staging/test AWS environment and then it would be much nicer to just do that from a branch where I have specified a forked socket-stream-client build in .meteor/ packages|versions.
I haven’t seen any note of such an ability but it seems it would be useful instead of forking the entire meteor project and publish all of meteor to atmosphere (or however people usually approach this - is there a way to publish to your own atmosphere repo?).