Hi, All: This was an even simpler fix than I hoped, there was a single "bad" require that needed to be fixed (see the PR and linked ticket for details). Here's the PR:
https://github.com/GPII/universal/pull/523 Cheers, Tony On Thu, Jul 6, 2017 at 10:05 AM, Tony Atkins <[email protected]> wrote: > Hi, Antranig. > > Thanks for confirming that is should be possible to avoid this behavior in > the post-fluid.require-world. I just checked out master and ran the node > tests, I got errors like the following: > > 09:51:28.838: FATAL ERROR: Uncaught exception: Cannot find module >> 'universal' >> >> Error: Cannot find module 'universal' >> > > This seems a clear symptom of using older less awesome require > strategies. As you suggest, I will reopen GPII-2151, happy to prepare a PR > to fix the regression, as this is very familiar from migrating to > fluid.require in other projects, and should not take long at all. > > Cheers, > > > Tony > > On Wed, Jul 5, 2017 at 6:03 PM, Antranig Basman < > [email protected]> wrote: > >> Cheers for the question, Gio. >> >> As of the merge of https://github.com/GPII/universal/pull/487 fixing >> GPII-2151, it *should* have been the case that all test cases will run >> properly regardless of the position of the checkout. They did at the time >> of the merge - but with the universal truth that functionality which is not >> tested is broken, this condition must have been broken by some test cases >> which were committed since that time (February this year). >> >> The issue is pretty simple to fix up. It is caused by an oddity with node >> module resolution which generally prohibits resolving a module name from >> within itself, unless its parent is named "node_modules". There was a lot >> of code which was a bit slack about this in the old days, for example, test >> code which would issue >> >> require("universal"); >> >> from within universal. This is faulty, but still seemed preferable to >> writing what it seems that node authors would have liked, which is >> something uncivilized like >> >> require("../../../../.."); >> >> which as well as being incomprehensible will break if the test is moved >> to another directory. >> >> For a while now this has been resolved by the Fluid module system API >> with docs at http://docs.fluidproject.org/infusion/development/NodeAPI.ht >> ml#fluid-require-modulename-foreignrequire-namespace- >> >> by replacing the call above with >> >> require("%universal") >> >> the problem is solved, but it is possible that not everyone got the memo. >> If some tests fail, and we care, we should i) reopen the JIRA GPII-2151 >> with a list of the failing ones and after it is fixed ii) change our CI for >> universal so that it checks it out to an ordinary directory. >> >> CHeers, >> >> Antranig >> >> >> On 03/07/2017 15:50, Tirloni, Giovanni wrote: >> >>> Hello, >>> >>> Regarding our requirement to have the universal live inside a >>> node_modules directory, could someone help me understand the machinery >>> behind that? Since some tests pass and others don't (when universal is not >>> living inside node_modules), does that mean this is a work in progress? >>> >>> I've found this JIRAs that seem to be related but I'm not sure they >>> document the situation completely: >>> >>> https://issues.gpii.net/browse/GPII-23 >>> https://issues.gpii.net/browse/GPII-36 >>> https://issues.gpii.net/browse/GPII-91 >>> https://issues.gpii.net/browse/GPII-492 >>> https://issues.gpii.net/browse/GPII-1527 >>> https://issues.gpii.net/browse/GPII-2151 >>> >>> I apologize in advanced if someone explained this to me before, my >>> memory is a bit blurry on this topic. >>> >>> Regards, >>> Giovanni >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> http://lists.gpii.net/mailman/listinfo/architecture >>> >>> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> http://lists.gpii.net/mailman/listinfo/architecture >> > >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
