0.0.8 breaks duo

[dominicbarnes]

Hey @matthewmueller, I tried to upgrade to file-deps@0.0.8 in duo, but it breaks a lot of functionality. Namely, #7 has caused duo to not rewrite things like @import "./one.css"; since the ./ is being stripped.

The mapping going to duo-pack basically looks like:

{ 'index.css':
   { id: 'index.css',
     type: 'css',
     mtime: 1431373205000,
     src: '@import "./one.css";\n\n.index {\n  color: white;\n}\n',
     deps: { 'one.css': 'one.css' },
     entry: true },
  'one.css':
   { id: 'one.css',
     type: 'css',
     mtime: 1417547024000,
     src: '.one {\n  color: green;\n}\n\n@import \'./two.css\';\n',
     deps: { 'two.css': 'two.css' } },
  'two.css':
   { id: 'two.css',
     type: 'css',
     mtime: 1417547024000,
     src: '.two {\n  color: red;\n}\n',
     deps: {} } }

The deps are now different, so duo-pack is not resolving them correctly.

Should this result in a change to duo-pack? Or is this a regression?

[matthewmueller]

Hm.. that sounds like a regression and I'm surprised I didn't immediately update to 0.0.8 when I released.

[dominicbarnes]

Well, duo-pack uses 0.0.x, so it gets 0.0.8 as expected.

However, duo uses ^0.0.7 which does not update to 0.0.8 automatically, it just keeps 0.0.7.

[dominicbarnes]

I believe the changes made for 0.0.8 need to be reverted.

The problem seeking to be addressed was the fact that the same deps could be represented in different ways. (eg: ./a.png and a.png) However, that should be normalized by the consumer of file-deps.

Any data that is stripped or modified by file-deps cannot be recovered by consumers, which is why duo breaks. The same applies for stripping the #hash from a URL for something like the IE font fix. There is no way duo can possibly resolve the original source again after that data was stripped.

@matthewmueller do you have the time to make such a change? If not, do you mind moving this to the duojs org as well so I can address it?