Closed thomas-jakemeyn closed 2 years ago
cc @bcheidemann, who might have thoughts.
Thanks for raising this issue @thomas-jakemeyn.
The problem seems to be that we import the whole of filer when we only need the FilerWebpackPlugin
class. In hindsight, this is obviously not the best idea! I will put up a PR to deprecate accessing the plugin through the "normal" filer import and add a specific import path for the plugin. @humphd what do you think about:
const { FilerWebackPlugin } = require('filer/webpack');
@thomas-jakemeyn Until the fix is released, you should be able to import the class directly:
// Direct import
const FilerWebpackPlugin = require('filer/src/webpack-plugin');
Let me know if this works for you! :)
Hello @bcheidemann,
I confirm that using a direct import as you suggested works. Thank you for that!
However, don't you think that the real problem is the side-effect on process.cwd
?
Hello @bcheidemann,
I confirm that using a direct import as you suggested works. Thank you for that! However, don't you think that the real problem is the side-effect on
process.cwd
?
@thomas-jakemeyn The process.cwd
side effect is, as I understand it, required for filer to work properly in the browser. Maybe @humphd can clarify the exact purpose? Regardless, the Webpack config only needs to load the FilerWebpackPlugin
class which does not import any part of the main filer library (nor should it). As such, if imported correctly, there should be no side-effects.
Are you having trouble with the process.cwd
side effect other than in the context of the Webpack config (i.e. at runtime)?
The problem that I was personally facing is solved with your suggestion.
re: the process.cwd
override, that can probably be removed. It's used very rarely, and likely could be dealt with through documentation alone. Unlike fs
running in the OS, we have no concept of a process
on which the current working directory can be managed. We could probably move this to the shell instead. I'd take a PR that did this, but am unlikely to have time to do it any time soon.
Thanks for the clarification @humphd.
@thomas-jakemeyn do you anticipate other issues that wouldn't be solved by PR #793? Happy to rethink our approach if there's reason to do so :)
Since filer
is intended to be used in a browser, I guess that it should be fine indeed. Thank you for the clarification and for the quick reaction!
No problem!
@humphd shall we proceed with PR #793 so we can close this issue?
EDIT: I have seen the other issue about the shims not being present in the version distributed through npm - don't have time to address that until this evening or tomorrow but we should probably ship any fix for that with the fix for this issue imo
Landed #793, I'll ship v1.4.0 in a min.
https://github.com/filerjs/filer/releases/tag/v1.4.0
https://www.npmjs.com/package/filer is now at v1.4.0
Thanks!
@humphd I think this issue needs to be reopened. I just checked the latest NPM release (v1.4.0) and the new import is not working. This is because I added a root folder called "webpack" which wasn't released to NPM. Could you advise on what I need to change so that this is included in the release to NPM? This is also the case for the "shims" directory which is the reason for issue #791
Should be fixed by v1.4.1
Should be fixed by v1.4.1
Confirmed, the correct files have been pushed to NPM
Context
I am trying to add
FilerWebpackPlugin
to an existing Webpack configuration.Problem
As soon as I
require('filer')
, Webpack starts failing because it cannot find the entry file anymore.Analysis
This problem seems to be caused by a side effect in
src/path.js
:Workaround
The only workaround that I found is to save
process.cwd
before importingfiler
, and to restore it afterwards.With this fix, Webpack is able to find the entry file again.