Closed Setogit closed 8 years ago
@bajtos PTAL
What are the consequences for existing applications? Is it expected to have the copied resource files submitted to git? If yes, then what will happen to applications that are already using long file paths? Will strong-globalize still load the files with long paths (starting with 32 char hash code prefix)?
There are no tests covering this change, could you please add some?
Last but not least, there are quite few downstream CI failures, are we sure they are not related?
Quickly examined the CI failures: I see 20 failing, 4 pending, 76 successful checks as of now. Approx. 60% of the 20 is clearly unrelated. 30% is probably not , but not that clear either without module specific knowledge. 10%, the log actually says success, but listed above as failed. No changes in loading side, i.e., if both exist, both will be loaded; if dup, overriden; those are important features. Offline, slt-globalize -l
detects duplicates.
TO-DO: document it in readme and add some tests. Consider minor version up.
Sounds reasonable. I'll trust your judgment, @Setogit.
document it in readme and add some tests
Great. Please let me know when you are done so that I can review again.
Consider minor version up.
Agreed, let's bump the minor version.
No README changes because it does not mention the 32 char hash in deep-extracted txt file names.
Moved the obsolete file removal out of the loop.
connect to https://github.com/strongloop/strong-globalize/issues/88