Opened 7 years ago

Closed 4 years ago

#14881 closed enhancement (patchwelcome)

Separate the Compressed and Uncompressed/Debug File Structures in Dojo Builds

Reported by: Elia Contini Owned by: Rawld Gill
Priority: high Milestone: 1.11
Component: BuildSystem Version: 1.7.2
Keywords: Cc: Patrick Ruzand
Blocked By: Blocking:

Description (last modified by dylan)

The Dojo tree should create separate uncompressed/debug builds, not nest every file with an _uncompressed throughout the tree. This would make the build system far more useful for debugging, as well as reduce the tree size for a standard build.

Change History (18)

comment:1 Changed 7 years ago by bill

Component: GeneralBuildSystem
Owner: set to Rawld Gill

What's the problem? Presumably it has the compressed files too.

comment:2 Changed 7 years ago by Elia Contini

Hi,

the presence of uncompressed files doesn't not generate any error. It's only a matter of cleanness and speed when I put / update dojo packages on my SVN or rebuild huge project on Eclipse.

Thank you for the quick reply. Elia

comment:3 Changed 7 years ago by bill

OK, well I think the uncompressed files are there by design, to help with debugging etc. Rawld?

comment:4 Changed 7 years ago by Rawld Gill

Resolution: invalid
Status: newclosed

Yes, Bill is correct. The uncompressed files have always been there (this is nothing new in 1.7) to help with debugging. It would be quite simple to write a shell script to delete files ending in ".js.uncompressed.js".

comment:5 Changed 7 years ago by dylan

Recently I received the request that rather than placing them in the same tree structure, that they be placed in parallel structures, e.g. /dojo/ and dojo_uncompressed/ (rather than each file name having the _uncompressed in it)... the reason stated for this was that these files are pretty worthless for debugging since there's no way to easily tell Dojo to use the files with the _uncompressed.js name, but it would be really nice to be able to just change the path to switch between uncompressed and compressed when debugging. This change would also make it easy for someone to just delete the uncompressed structure if they didn't want it. The request was also made that when this is done, it should also be done on the CDN to make it easier to test against it. Thoughts?

comment:6 Changed 7 years ago by bill

Probably, each release should just include a "debug build" with all the uncompressed files, although not sure how that would be different than source... I guess having the templates interned and layers built.

comment:7 Changed 6 years ago by dylan

Resolution: invalid
Status: closedreopened

comment:8 Changed 6 years ago by dylan

Description: modified (diff)
Milestone: tbd1.9
Priority: undecidedblocker
Summary: Dojo 1.7.2 release package contains uncompressed filesSplit Uncompressed Tree from Dojo Builds

comment:9 Changed 6 years ago by dylan

Summary: Split Uncompressed Tree from Dojo BuildsSeparate the Compressed and Uncompressed/Debug File Structures in Dojo Builds

comment:10 Changed 6 years ago by cjolif

Cc: Patrick Ruzand added
Type: defectenhancement

I agree this can be useful. Actually pruzand Dojo-Build-Factory (https://github.com/pruzand/Dojo-Build-Factory) is doing that as a post processing step I suppose, ideally he should not have to post-process and this should be a build option. That said this is more a enhancement than a defect I suppose. As a solution is to use Dojo-Build-Factory I would personally not consider this as 1.9 blocker even it would be more than nice to get it.

comment:11 Changed 6 years ago by cjolif

Milestone: 1.92.0

per meeting decision punt to 2.0

comment:12 in reply to:  8 ; Changed 6 years ago by Rawld Gill

Milestone: 2.01.9
Priority: blockerhigh
Status: reopenedassigned

Replying to dylan:

In answer to your question at comment 5...sometimes it is useful to rename or map (via loader config) a single(or a few) resource(s) that are having problems...many minification-induced bugs can be diagnosed this way...at least that's my experience.

I have no problems adding this feature, though I am slightly concerned that we'll get complaints about changing a behavior that's been there forever. Can you tell me the use case that caused this to be such a high priority so I can make sure we're solving the root problem.

comment:13 Changed 6 years ago by ippon-solutions

We're developing an application with this use case - I understand the reasoning in the past for the inclusion of the uncompressed files. For a release build however, there is no need for these files to be included and currently requires an extra step for us to remove the files before releasing onto our production environment. I would say, there is justification to have 2 types of build; one that includes the uncompressed files for debugging, and another true 'release' build which doesn't include these files. Additionally, it may be good to have a function in the profile.js like amd/test/miniExclude which allows developers to configure which files are copied/included in the build folder.

comment:14 in reply to:  12 ; Changed 6 years ago by cjolif

Replying to rcgill:

Replying to dylan:

I have no problems adding this feature, though I am slightly concerned that we'll get complaints about changing a behavior that's been there forever. Can you tell me the use case that caused this to be such a high priority so I can make sure we're solving the root problem.

Rawld, I see you moved that one back from 2.0 to 1.9 (punting it was decided in meeting). To be honest I would love to see that one, but we are passed the enhancement/feature deadline for 1.9 and I don't think we should risk breaking anything for that even if that is a very useful feature. At that point in time only bug fixes are supposed to get in, I would not like to see the release delayed because we broke something for a feature past the feature deadline. Does it make sense for you as well?

comment:15 in reply to:  14 Changed 6 years ago by Rawld Gill

Milestone: 1.91.10

Replying to cjolif:

Does it make sense for you as well?

Yes...I'm totally fine and in support of your pov. I'd also like to take some time and get a little more feedback and define the key requirements to fully solve the problem.

comment:16 Changed 5 years ago by richso

I am also extremely require this feature together with others feature (which I specified below) as I've written a HTML5 application which using the HTML offline functionality for executing in offline situations; I found this feature help to generate a neat structure of files for manifest caching.

the additional features required are:

  1. a feature for selection of only some language resources files for use
  2. remove the files which are already combined into the 'layer' target file or unused language resources files; or generate a neat structure of files which do not including these unused files
  3. it will be nice if the build process can be incorporated into IDEs, e.g. Netbeans, Eclipse, etc.
Last edited 5 years ago by richso (previous) (diff)

comment:17 Changed 5 years ago by dylan

Milestone: 1.101.11

comment:18 Changed 4 years ago by dylan

Resolution: patchwelcome
Status: assignedclosed

Unfortunately this is not going to be solved for Dojo 1.x unless someone spends significant time working on the build system.

Note: See TracTickets for help on using tickets.