MegaJSDeveloper
commented
4 years ago if you want, I can help you write such an build system) agree that it is very easy to implement, just couple of days =).
By the way, I would generally use the webpack system to implement this. I founded a new meteor assembly system on webpack 4.0 and wrote a webpack plugin so that webpack implements the current behavior of the Meteor assembly. The benefit of the flexibility of webpack allows this. And that's it, the meteor under the hood would have a Webpack. which would allow us to add support for loaders and other chips.
Well, that is, inside the meteor, I would do like this:
webpack = new Webpack({
plugins: [new MeteorWebpackPlugin()]
})and i would do all the magic in MeteorWebpackPlugin, forcing he to behave like a standard meteor builder. Next, I would make some kind of config meteor.config.js
And I would come up with a special api to configure the meteor assembly system so that people can add loaders and more. and we ourselves, as we need it, would integrate them with the webpack.
In fact, we would simply tell people: Now the meteor has accelerated the build system, and supports webpack loaders. Although under the hood we would have a real webpack, ahaha.
In other words, since the webpack specializes in project building, we can use it UNDER THE HOOD of a meteor. By changing its behavior with the help of our plugin, and forcing to behave like a standard Meteor build system. we can even write a new api for build packages that actually will transparently pass all these settings to the webpack engine, and the user will not even know about it.
This way we won’t lose backward compatibility and give people new features, such as faster builds, hot module reload, tree shaking, and support for loaders.
Isomorphic import is a EPIC feature to Meteor, reflecting the whole nature of the Meteor
Since the meteor uses its own build system, which is different from the webpack, it should not be flawed in comparison with the webpack, but EXCEEDING it, and reflecting the isomorphic essence of the Meteor platform. The loss of backward compatibility is achieved by the usual inclusion of the
isomorphicImport: trueflagso that we can come up with a good, truly isomorphic build system without holding onto the legacy as a heavy anchor.
If Meteor not found
window.coffeefile, he try get isomorphic import adds env to file name, likewindow.server.coffeeorwindow.client.coffeewe can support different environments in order of priority, first there are specific platforms (mobile) (cordova) (electron) (browser) (legasybrowser), if there is no specific platform file, a more general platform is searched, for example, "client" or "server"
Priority is such, specific platform names come first:
chrome,firefox,cordova,nodejsThen there are types of platforms:client,server,desktop.the first file that comes in is imported, and the search process stops. different if we are in cordova, and we have two files cordova and client, cordova is imported, the client will not be processed, despite the fact that cordova is a client. if we are in a browser, then client will be messed up.
Also, a similar function would not be just a package. To do this, you can enable the special flag
isomorphicImport: truein package.json.if a person turns on isomorphicImport: true at the package.json level of his application, then the meteor enters a completely different assembly mode. programmers are no longer required to store files in the
importsfolder for backward compatibility; files are no longer imported automatically at the project level. the meteor goes into a new, thoughtful, truly isomorphic mode!Just imagine
Default file version:
if we in cordova will imports
logger.cordova.coffeeelse will importslogger.coffeeorlogger.default.coffeeIt also works with templates or any files:
Only the mobile template will get into the mobile assembly, and only the computer one in the computer.
SRR and isomorphic imports
But if we in server envorement, how can we request a mobile component file branch? easy, we apply the environment injection through an exclamation mark, and the further chain of imports will be carried out in a forcefully defined environment:
Now the further import branch caused by the Panel.coffee file will happen as if we are surrounded by mobile. this is similar to webpack loaders, we can, when we need to, forcibly import a branch for a certain environment.
I would also probably make one small trifle that will make people's lives easier. I would prohibit importing .server environment files in a client environment, and would give a hard error. a person may not keep track of and accidentally import something from server enviroment, secret. this protection will help to avoid this, and everyone will get better from it. but of course, no one forbids importing the client branch on the server =)
Future Meteor
By the way, using such a build system, we can add different environments, electron, nativescript, and indeed anything. just think about it! we can also add APIs to add new platforms so the community can add them. competently twisting environment code branches, people will be able to fork the code where they need it and back connect where they need it. this have not happened before.
Meteor will be the first platform in the world capable of creating REALLY, LITERALLY isomorphic code for ANY PLATFORM IN THE WORLD! It will blow the market!