You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I watched your talk "Everything is a plugin!" and really enjoyed it; it helped to demistify the plugin ecosystem a fair bit. Recently I've been trying to develop my own plugin that would help manage a large project made up of many micro frontends, but I could really use your advice on what I can do better if you have the time.
Bit of context about the plugin first might help. The plugin focuses purely on allowing users to enforce rules as to whether a given apps modules are allowed to import modules from a seperate app.
The use case is quite a niche one because it really only makes sense when you are generating multiple bundles and you want them to be able to interact in certain ways. It also requires that webpacks library option is set (so each bundle is assigned to a variable).
I've made a repo on github with a minimal example showcasing it's functionality, which also has more of an explanation as to why you might need it. Here's the link:
Some of the things I could really use your advice on are:
Am I tapping into an event too late in the lifecycle? My first attempt (which can be found in old.js) was to try tap into the resolvers lifecycle but I was having trouble finding a place where I had both the modules full path and its dependencies full path.
How do you go about throwing an error properly, especially one that actually stops the bundle from still compiling? Because this plugin is just enforcing more rules on imports, you can still have a perfectly valid project even if it finds a violation. Therefore it still compiles but just shows my error message below that. Currently I'm using the FriendlyErrorsWebpackPlugin to hide the compilation details but this approach is pretty sucky (needs more than just my plugin and it doesn't actually prevent compilation).
This relates to Question 1 but I would also really like it if I could reliably show the line that the improper import was happening on. I attempted it with my plugin, however I only had access to the transpiled code so mapping it back to the original file was hacky to say the least (find the line that contained the import substring and counting the requires before it). If you knew a way to do this that would be awesome.
Have you ever seen any other use case for something like this (or even a plugin that does the same thing)? Maybe what I'm trying to do makes no sense but I'm in too deep at the moment haha.
Thanks a ton for your time, I'm really keen to get your feedback. Let me know if you have any questions or if something I said made no sense, I'll answer as quickly as I can :)
The text was updated successfully, but these errors were encountered:
Hey Sean,
I watched your talk "Everything is a plugin!" and really enjoyed it; it helped to demistify the plugin ecosystem a fair bit. Recently I've been trying to develop my own plugin that would help manage a large project made up of many micro frontends, but I could really use your advice on what I can do better if you have the time.
Bit of context about the plugin first might help. The plugin focuses purely on allowing users to enforce rules as to whether a given apps modules are allowed to import modules from a seperate app.
The use case is quite a niche one because it really only makes sense when you are generating multiple bundles and you want them to be able to interact in certain ways. It also requires that webpacks library option is set (so each bundle is assigned to a variable).
I've made a repo on github with a minimal example showcasing it's functionality, which also has more of an explanation as to why you might need it. Here's the link:
https://github.com/Francesco-Lanciana/prevent-cross-project-imports-webpack-plugin#
Some of the things I could really use your advice on are:
Am I tapping into an event too late in the lifecycle? My first attempt (which can be found in old.js) was to try tap into the resolvers lifecycle but I was having trouble finding a place where I had both the modules full path and its dependencies full path.
How do you go about throwing an error properly, especially one that actually stops the bundle from still compiling? Because this plugin is just enforcing more rules on imports, you can still have a perfectly valid project even if it finds a violation. Therefore it still compiles but just shows my error message below that. Currently I'm using the FriendlyErrorsWebpackPlugin to hide the compilation details but this approach is pretty sucky (needs more than just my plugin and it doesn't actually prevent compilation).
This relates to Question 1 but I would also really like it if I could reliably show the line that the improper import was happening on. I attempted it with my plugin, however I only had access to the transpiled code so mapping it back to the original file was hacky to say the least (find the line that contained the import substring and counting the requires before it). If you knew a way to do this that would be awesome.
Have you ever seen any other use case for something like this (or even a plugin that does the same thing)? Maybe what I'm trying to do makes no sense but I'm in too deep at the moment haha.
Thanks a ton for your time, I'm really keen to get your feedback. Let me know if you have any questions or if something I said made no sense, I'll answer as quickly as I can :)
The text was updated successfully, but these errors were encountered: