Sub-dependencies of bundle dependencies are going into wrong bundle #342
Comments
|
I want to add that, because of this bug, also the generated source.map is technically wrong (I mean based on the specification found here ). ADDENDUM You can see that, in place of the source code of library files, you have null values, and that's a specification error.. |
|
I've done some more investigation, and it seems that aurelia-cli is not doing dependency analysis on the specified Trying to run the This output could be easily mapped to |
|
@Nexbit, this definitely seems like it shouldn't be happening. Can you reproduce this by creating a new project from scratch with the CLI? I have not experienced this behavior on any of my CLI projects. |
|
Sure, I'll try asap! Did you find something looking wrong in my dependencies section? Just to be sure I'm not missing something obvious ..
|
|
Thanks. And no, the bundles config looks normal, as far as I can tell. |
|
Hi
If I run IMHO the issue is related to the analysis of source files' dependencies, that obviously are too many to post here.. If you want to give me a hint on where to look for the src files analysis in the cli sources, maybe I could find a way to debug it on my project. Thx, P. |
|
First thing, I don't believe |
You're right, it was a mistake in my post. The command I run was
Yes, you're right. The steps I mentioned in my previous post were done with the original The second test were to open the The third test were to go in Finder, and simply copy my The difference between the second and the third test is merely the content of the |
|
Okay, thank you for clarifying, I wasn't tracking exactly what you were saying :) |
|
Also, you say you're pulling in bower modules. Is there a reason you specifically want to pull them down via bower instead of npm? And how are you including them in your package? Are they in your |
Well.. I don't know, and even if the codebase is not huge, it's not small either! I'm porting over an existing project from jspm to the cli, and I'm half the way in the process.
That doesn't matter for this issue. I tried without them, and nothing changes anyway.
Can you define strangeness from the CLI's point of view? |
|
I want to add that the packages that got incorrectly bundled in A single-file dependency is never put into |
|
@AStoker Were you able to confirm this behavior? Would you have any bandwidth to look into addressing it? |
|
@Nexbit, the CLI shouldn't be defining correctness, didn't mean to come across that way. Just as a disclaimer, the CLI is still in alpha, the price of living on the bleeding edge of technology is that you might bleed a little bit ;) Now, I almost spoke to soon. I was able to reproduce the error, but it was different from yours. We're using the CLI on a large project, pulling in many of the resources you mentioned, and specifically the Now, the dialog module seems to be putting things on the I will try to figure out why aurelia dialog is being bundled in the wrong place, and hopefully that will solve your problem @Nexbit. In the mean time, can you send me what your @EisenbergEffect, I have a little bit of bandwidth, so I'll put some time in, but right now at the office we're trying to solve our issue of testing our application with source code so we can actually do test driven development. I'll have a write up for a proposal I'd like to implement to the CLI to help with this (it will also solve issues with users testing with Wallaby). And don't worry, it's different than what I had initially proposed. |
Yeah, I can confirm that, as I stated in my last comment, and the culprit is that they are multi file dependencies.. Single file dependencies never gets bundled in the wrong place. Are you bundling some other dependency I mentioned in my list, for example |
|
I can confirm that the root file is being bundled appropriately. |
|
I'm still digging into this (it's kinda kicking my butt right now, since there are still parts of the CLI I'm learning about). A thing of curiosity is that it seems the Amodo Trace function we call in the |
|
@AStoker That's really interesting, good catch! Well, if that's the culprit, maybe the CLI can treat the EDIT: only multi-file AMD style dependencies need this special treatment, I suppose |
|
I believe this is the area that our troubles are realized (https://github.com/aurelia/cli/blob/master/lib/build/bundled-source.js#L85). |
As a TL;DR of the issue at handWhen you have a vendor library being imported (the vendor library has been defined in the The reasoning for this is that during the bundling process, vendor files are not traced for dependencies, and therefore any file dependencies are not included properly. But when the tracing does begin on the app code, it traces the dependencies of the imported vendor files, and places them inside the |
|
How can we then write a bundles definition to put all of (say aurelia-dialog) into the vendor bundle? With this definition as per the doc: we get the following files in the app bundle: |
|
@sensedeep Unfortunately you can't as long as this bug is not fixed.. We are still investigating a solution for this. |
|
Thanks. I can help test when you have a fix. |
|
I was digging into this, and got as far as I did with my last post. Unfortunately, my priorities got shifted a bit at work, so I'm working on a different feature for test driven development. As of right now, we know the problem... But not the solution. If you're able to help out figure a way to solve this, that would be greatly appreciated @sensedeep |
|
Sorry, but absolutely buried launching SenseDeep. I'd recommend being able to provide a list of files in the aurelia.json bundle group as a work around. Easier than tracing and would 100% solve the issue. |
|
Can I a general question related to this? Exactly what does Tracing achieve? The transpiled code has the define declarations added with dependent modules. Assuming that all the source is being compiled and bundled into a file, why not just catenate the source without tracing? When the file is loaded, all define statements will be executed and the dependencies are handled by requirejs. So what does build time tracing achieve? What am I missing? |
|
One thing that may not be obvious is that the tracing process also converts the code into a module format that can run in the browser. You may be right that there could be a way to remove the tracing and just convert the code to the proper format. I'm not sure that would cover all cases though....so I'd be worried about making that change. I'm not sure it would work correctly with dependencies, especially those distributed as multiple modules. eg. aurelia-templating-resources or aurelia-dialog |
|
I can imaging code with a buried require() somewhere in the code that the tracing might pick up. What is the transformation required to make it run in the browser? It looks like standard AMD declarations. I was wondering if the compiler babel or tsc could emit the list of modules while compiling somehow. They have the canonical understanding of what modules are being used when they compile the application source -- as ES6 modules are by definition static. I don't have any concrete suggestions, but it just feels like there must be an easier way. I'll see what I can explore. |
|
Yes, amd, but they have to be non-anonymous modules. That's part of what the trace process does. Please explore :) We would love to improve this. I wondered if there was a way to replace amodro trace with something like rollup, for example. |
|
Playing with rollup and it looks promising so far. Extremely fast with a good stable of plugins. I can flexibly target any desired module output with a good go-forward bias to ES modules. Via plugins, can parse modules in a wide variety of formats and convert on output. The question is whether when fully configured it is as complex as what we have now. I'd recommend a good deep look at this as an alternative. I'll keep digging. |
|
@sensedeep Thanks for looking into it. I'd love it if we could leverage something like that internally instead of amodro trace. I personally don't know enough to understand if it's a good fit or not. I look forward to hearing more from your research. Thanks for being willing to help. |
|
I guess I'm experiencing the same issue which also leads to a poor debug experience of 3rd party dependencies. What's the current status of this issue? Are there any plans to resolve it in the foreseeable future? |
|
I'm using the 0.25.0 version of aurelia-cli and it works for me when I explicitly define the resources (*.js is also important): |
|
I have taken a look at this issue and can confirm what's said in this issue. To reproduce, add a dependency to the vendor-bundle config.: where the main file of this plugin ( What you get is that the The difference between When you register But it should not be necessary to do this, so ignore it for now. Why the main file ends up in the The core issue is this: Even though we tell the CLI not to trace (and bundle) dependencies of the source files because of the This happens because AmodroTrace executes @EisenbergEffect what are your thoughts about possible solutions? |
|
Ultimately, for dependencies, we want all the code related to that dependency to go into the same bundle that we defined the module entry point in. I'm not sure what the best way to do that technically is. I haven't looked deeply into that code for a while. @JeroenVinke Would you be willing to try to put together a proposal? |
|
The fix may be simpler than I thought... Instead of assuming that this.includedBy is the correct DependencyInclusion, we could look up the DependencyInclusion based on the path of the file that's being included and the Current situation Result of change |
|
Give it a shot 😀
…On Mar 14, 2017 2:09 AM, "Jeroen Vinke" ***@***.***> wrote:
The fix may be simpler than I thought...
Instead of assuming that this.includedBy
<https://github.com/aurelia/cli/blob/d6f0ada18c4832bf0ec8296175ef1862047dce56/lib/build/bundled-source.js#L105>
is the correct DependencyInclusion, we could look up the
DependencyInclusion based on the path of the file that's being included and
the path of the each registered dependency.
*Current situation*
[image: image]
<https://cloud.githubusercontent.com/assets/2189477/23893259/18715cc6-089e-11e7-8b3e-eb593b770697.png>
*Result of change*
[image: image]
<https://cloud.githubusercontent.com/assets/2189477/23893263/1b2ef810-089e-11e7-860b-8bbe444621a3.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#342 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIBnQp9wrFCG5GALOuQTKEltu6g7ly9ks5rllkzgaJpZM4KHgMm>
.
|
I'm submitting a bug report
0.20.0
Please tell us about your environment:
Operating System:
OSX 10.11.6
Node Version:
6.4.0
NPM Version:
3.10.8
Browser:
all
Language:
TypeScript 2.0
Current behavior:
When you have the standard bundling config in
aurelia.json(one vendor-bundle and one app-bundle), only the root file of listeddependenciesgoes into the vendor-bundle, while the rest of the package files goes into the app-bundle.Here is an example of
bundlesnode inaurelia.jsonfile:Take for example the
aurelia-authenticationdependency: only the main file (aurelia-authentication.js) goes into the vendor-bundle, while the dependent files goes into app-bundle..Expected/desired behavior:
Every sub-dependency of a dependency in the
vendor-bundleshould go into thevendor-bundleand not into theapp-bundle.The current behavior defeats the purpose of having separate bundles, especially when the
app-bundlegets polluted with library (not user) code.The text was updated successfully, but these errors were encountered: