pattern-lab / edition-node-gulp

ARCHIVED - The gulp wrapper around patternlab-node core, providing tasks to interact with the core library and move supporting frontend assets.
MIT License
279 stars 111 forks source link

Serve fail to buildPatterns, with or without incrementalBuild #119

Open DruMasterMunch opened 6 years ago

DruMasterMunch commented 6 years ago

I am using Pattern Lab Node- Gulp Edition v3.0.0-alpha.7 on Windows.

Expected Behavior

gulp patternlab:serve should build pseudoPatterns, and then be able to watch for changes and rebuild

Actual Behavior

gulp patternlab:serve succeed in building pseudoPatterns in the first place (everything is fine in patternlab), but fail on watching changes:

when incremental build is enabled, this error occured:

Error: Pattern not known: atoms\btn.mustache
    at Object.link (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\lib\pattern_graph.js:131:15)
    at pseudopattern_hunter.find_pseudopatterns (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\lib\pseudopattern_hunter.js:98:24)
    at module.exports (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\lib\processIterative.js:12:6)
    at Promise.all.patterns.map.pattern (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\lib\patternlab.js:559:18)
    at Array.map (native)
    at promiseAllPatternFiles.then (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\lib\patternlab.js:558:23)
Error in buildPatterns()

Now with incremental build disabled, this error:

Error: ENOTEMPTY: directory not empty, rmdir 'Z:\Web\testpatternlab\public\patterns'
    at Error (native)
    at Object.fs.rmdirSync (fs.js:887:18)
    at rmkidsSync (Z:\Web\testpatternlab\node_modules\rimraf\rimraf.js:356:25)
    at rmdirSync (Z:\Web\testpatternlab\node_modules\rimraf\rimraf.js:334:7)
    at Function.rimrafSync [as sync] (Z:\Web\testpatternlab\node_modules\rimraf\rimraf.js:304:9)
    at Object.removeSync (Z:\Web\testpatternlab\node_modules\fs-extra\lib\remove\index.js:4:17)
    at cleanBuildDirectory (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\index.js:165:10)
    at buildPatterns (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\index.js:197:5)
    at Object.build (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\index.js:355:14)
    at PatternLabEventEmitter.events.on (Z:\Web\testpatternlab\node_modules\@pattern-lab\patternlab-node\core\index.js:366:27)
Steps to Reproduce

On fresh install, creating a pattern _patterns/atoms/btn.mustache :

and create 2 json files: _patterns/atoms/btn.json => {"text": "Test"} _patterns/atoms/btn~core.json => {"text": "Core"}

launch gulp patternlab:serve Everything should work fine, and the 2 differents buttons are displayed in patternlab Now trigger any change in one of those file And one of the error described above should appear, depending on whether or not IncrementalBuild is active

To test with or without incrementalBuild, i'm forcing it in the file node_modules\@pattern-lab\patternlab-node\core\index.js adding this line 192 : patternlab.incrementalBuildsEnabled = false;

Thanks for your feedbacks

DruMasterMunch commented 6 years ago

Tested with version 2.0.0 => same bug Tested with version 1.4.0 => works fine

bmuenzenmeyer commented 6 years ago

Thank you so much for the thorough report! With alpha work changing quite a bit of internals it's been easy to break even the simple things at times. I've seen both of these issues before but the isolated test case is a godsend.

Stay tuned

bmuenzenmeyer commented 6 years ago

To test with or without incrementalBuild, i'm forcing it in the file node_modules@pattern-lab\patternlab-node\core\index.js adding this line 192 : patternlab.incrementalBuildsEnabled = false;

FWIW - incremental build is controlled by http://patternlab.io/docs/advanced-config-options.html#cleanpublic though in this case it looks like it may be running either way

raphaelokon commented 6 years ago

I just did the same test suite against dev—works like a charm with incremental build turned on ("cleanPublic" : true,). It however breaks with the first error when "cleanPublic" : false, is set.

raphaelokon commented 6 years ago

I investigated this further. It seems to be a bug with the PatternRegistry. On the initial run I get the following dump from it (pattern_graph.js:131:15):

--------
name: 10-atoms/btn~core.json
fileName: btn~core
--------
name: 10-atoms/btn.mustache
fileName: btn
--------

=> Make change to any file

--------
name: 10-atoms/btn~core.json
fileName: btn~core
--------
name: 10-atoms/btn.mustache
fileName: undefined
--------

It cannot retrieve the pattern from the Map.

raphaelokon commented 6 years ago

Maybe @tburny can take a look as well.