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
