I’ve done a good deal of research on this plugin, but I still don’t understand this part.
What does a production rollout of a new breaking major version of let’s say React look like, when you’re using module federation and continuous deployment (and multiple modules use React)? Things to consider, is there a pattern for releasing all related modules with the updated dependency in an atomic way? Ideally you wouldn’t need to. What does and how should this look? Production ready examples only please, ty!! I haven’t seen this described anywhere.
Things shared with a singleton can cause issues between major versions. In the case of react, 17 and 18 have the same internal api so i can use v18 components in v17 hosts.
However in other cases, like say redux - theres no good solution.
In cases like react, i have a demo called different-react-versions which shows an example of importing another version of react and rendering component on a ref.
Related
I need to find out how I can instruct Vite to replace references to local/relative modules at runtime. The use case here is the test runner mocha-vite-puppeteer, which uses Vite to run tests, but then stubbing of modules of course does not work when using Node machinery such as proxyquire or rewire.
So I basically need to either be tipped of some existing software that can help me in doing this, or some tips on how to create my own "vite-proxyquire" using import.meta and friends.
A normal use for temporarily stubbing out ./my-ugly-module might be that you want to avoid loading some sub-dependency that has some ugly transitive dependencies that suck the entire application tree into your little test, or you want to avoid loading a sub-dependency that has some ugly side effects on the global state.
Existing solutions
Modern Web, a refreshing "bundler- and frameworkless" approach to web development using standard tools, talk a bit about the issue around how the immutable nature of ES Modules prevent usual stubbing patterns. They present a solution in the form of Import Maps, which essentially would be similar to the alias config in Vite (Rollup really), mapping a path to a module to some other file. The problem with a static solution like this is that it would replace all imports of a given module, not just for a single test. Modern Web has a solution to this where they have chosen to use a custom html page for each such test. To make this less of a hassle with regards to running, they then have a custom test runner that handles dealing with all these extra test html files. Doing something like that could be one way of fixing it, but it would require developing quite a bit of middleware/plugin code IMHO to make it work transparently with Vite. Without any advanced tooling it would also introduce a lot of extra files that seems a bit of a downside compared to todays imperative mocking of dependencies with proxyquire, Jest or Test Double from inside of the test files.
I'm currently building a web app which is intended to run on an isolated, offline environment. However, semantic imports fonts from Google's datacenter by default (a terrible practice if you ask me), which obviously aren't reachable from this environment, hanging the app for 10 or 20 seconds until it times out.
Is there a way to prevent this behaviour?
I've read things about gulp here and there, but honestly I don't even know what gulp is. All I've used is npm/yarn.
Thanks in advance.
Using gulp is your most reliable approach, and this guide makes it easy to follow:
http://g14n.info/2016/11/react-semantic-customized/
Your second option would be to use a forked version of their CSS like this one:
https://github.com/arthurlacoste/semantic-ui-offline
I hate to ask such a newbie and vague question, but I imagine there must be others out there whose brains are also about to explode. I see related questions, but none that directly addresses my confusion.
I've just been introduced to Ember.js and I'm trying to learn the basics of the Router, but I can't find two sources that agree on how this is done. I suspect that I'm jumping in during an unstable transition. I'm using the latest 1.0.0-Pre.4 release.
The best I can figure, Router is the new mechanism, and possibly replaces StateManager - yes? Yet the classes listed under 1.0.0-Pre.4 API on the web site don't even list a Router object, nor does the guide make mention of it... yet, I get no complaints from javascript when I use sample code that extends Em.Router.
Ok cool, however it then barfs on the Router member "transitionTo" which is present in many of the demo projects, but is unrecognized in the current release.
So, I guess what I'm asking is not so much a direct question, as I am looking for a grounding point in a sea of contradictory information.
If starting out with Ember.js as it is RIGHT NOW (1.0.0-pre.4), with no history to contend with, what routing mechanism should I be looking at, and is there any tutorial or simple sample app that demonstrates and runs against this version of the library? Can you confirm my suspicion that the documentation is out-of-date in regard to routing?
Ember.js is a lot to learn, and if I ever hope to figure it out, I need to know what to ignore and what to embrace.
Thank you.
The best I can figure, Router is the new mechanism, and possibly replaces StateManager - yes?
Yes, Router is the new mechanism. It does not replace StateManager per-se. Early version of the Ember Router were based on StateManager. The new one (1.0.0-pre.4) is not, but StateManager is still an important part of the ember library. Many of ember's core components (models, views) rely are built on StateManager.
Yet the classes listed under 1.0.0-Pre.4 API on the web site don't even list a Router object, nor does the guide make mention of it... yet, I get no complaints from javascript when I use sample code that extends Em.Router.
The Router does not have API docs yet. I imagine these are in the works. When in doubt about a fast-moving open source project I always have a look at the tests. Ember has a really solid test suite, and in the case of routing you can learn a lot by reading through the integration tests here: routing/basic_test.js
Ok cool, however it then barfs on the Router member "transitionTo" which is present in many of the demo projects, but is unrecognized in the current release.
Sounds like those demo projects are out of date.
Can you confirm my suspicion that the documentation is out-of-date in regard to routing?
Re: the official docs I think both the API and Guides can be considered current, but be aware that not every ember feature has API docs so far. For sure there are many out-of-date sources floating around. Trek has been working to compile a list of out-of-date sources so that we can reach out to authors for a refresh. Here on Stack Overflow, anything related to the old router should now be tagged https://stackoverflow.com/questions/tagged/ember-old-router.
If starting out with Ember.js as it is RIGHT NOW (1.0.0-pre.4), with no history to contend with, what routing mechanism should I be looking at, and is there any tutorial or simple sample app that demonstrates and runs against this version of the library?
The ember team has been putting a lot of effort over the past few months into the Ember.js Guides - AFAIK they are all up to date WRT (1.0.0-pre.4) and are becoming more solid every day. They include a lot of detail about the new Router - see Ember.js - Routing for the most up-to-date information.
As for tutorials, there are several new ones that are worth a look. Check out this SO post for a few recommendations: Could someone point me to an ember.js project that uses the latest routing system? Bonus points if it uses ember-data as well
tip: build your own version of ember from master branch - they fixed few bugs :)
With the move from SproutCore 2.0 to EmberJS there was the namespace and Github repo migration. Core things seem to have moved to the http://github.com/emberjs organization Github account while there are some others that seem to have been moved to the "addons" account http://github.com/emberjs-addons.
I am currently investigating EmberJS for use with a RESTful server, serving up JSON.
My question is: Do I use the new http://github.com/emberjs/data code or the older http://github.com/emberjs-addons/sproutcore-datastore code? I would assume the former but I would just like to be sure as well as get some clarification on what is going on with the old SproutCore "addons".
The emberjs-addons are ports from the old sproutcore ecosystem. They are not modified and it looks like they are not receiving much attention from the emberjs core-team. They are concentrating on the new "emberjs-data". However, the old datastore is production proven and the modified version does work fine with the current emberjs relase (0.9.3).
In contrast, while the rewritten version looks really nice, it is explicitly stated in the projects readme that it is not considered "production ready", yet.
Which one should you choose? In my opinion that depends on your project. If you are looking for something stable or you want to put your app in production any time soon, I would give the "old" sproutcore datastore a go. On the other hand, if you are just starting with your project use the new and shiny "emberjs-data" but be warned that you might have to fight around some edges.
I have been using ember-models with my own REST adapter while I am waiting for the ember-models one to be completed. git://github.com/ebryn/ember-model.git
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.