Error at build-time if an application bundle includes paths that cannot be resolved

[WilliamKelley]

Feature request: meteor should fail to build if it encounters an resolution of a path that does not exist.

I do not understand why an error is outputted only at runtime that a module cannot be resolved. For example, importing from a file that does not exist, importing from a special directory that does not exist (e.g. server/ from client/, or vice versa). It seems that the responsibility of this falls to the "modules-runtime" package which will say something like "Error: Cannot find module '../client/main'". This is an appropriate error, but one that I expect can and should be statically detected at build time.

A very negative example outcome of this behavior is that you can deploy your application to Galaxy with no errors, only to find out that the client application cannot reach the login screen because of a bad top-level import statement.

[zodern]

Sometimes there are situations where files are optional so even if Meteor can't find them, the app still runs fine (some examples are in #9285). We might be able to create a limited scope where we can error at build time. Maybe something like:

• path starts with . or /
• path does not include node_modules
• uses the static import syntax (not require or a dynamic import since those can be used for optional deps)
• not a nested import

Though there are still edge cases with those restrictions where Meteor would crash when there is a missing optional file or dep.

[WilliamKelley]

That would be satisfactory to me! I was primarily concerned with top-level import/export of project file modules. Thank you for the quick response and suggestion.