ExpandGlobs add prefix '/'

[dean-shanghai]

following inputFiles + debug mode (no bundling and minification), the output js paths missing prefix "/"! { "outputFileName": "/lang.min.js", "inputFiles": [ "/i18n/**/*.js" ], "minify": { "enabled": false } },

[madskristensen]

Does this mean that all href and src attributes will always be rooted with a / at the beginning? Are there any consequences to that?

[skimedic]

What problem is this trying to solve?

[dean-shanghai]

Does this mean that all href and src attributes will always be rooted with a / at the beginning? Are there any consequences to that?

1. in release mode (bundle + minify), there is no problem, because the outputFileName path will be used;
2. while in debug mode (NO bundling + NO minification)

• without the prefix '/': those unbundled css/js files' path will be relative to the current page Url, which will cause 404!
• and all the css/js resource files are in the wwwroot folder, so rooted with a '/' is OK.

[dean-shanghai]

What problem is this trying to solve?

Trying to fix the path problems in DEBUG mode when using wildcards inputFiles like the following: "inputFiles": [ "/jsfolder/**/*.js" ]

[skimedic]

Aren't you using services.AddWebOptimizer(false, false); in development mode?

[dean-shanghai]

Aren't you using services.AddWebOptimizer(false, false); in development mode?

No, i'm not specifying the minify flag, just let the running mode decide to minify or not.

I'm USING WebOptimizer.Core and WebOptimizer.Core.Sass Source Code from github; NOT using nuget packages (because of the path problem);

Code using:

        services.AddWebOptimizer(pipeline =>
        {
            var bundles = BundleHandler.GetBundles(Configuration["SiteSettings:BundleConfig"]); //using nuget package: BundlerMinifier.Core
            foreach (var bundle in bundles)
            {
                if (bundle.OutputFileName.EndsWith(".css"))
                {
                    pipeline.AddScssBundle(bundle.OutputFileName, bundle.InputFiles.ToArray());
                }
                else if (bundle.OutputFileName.EndsWith(".js"))
                {
                    pipeline.AddJavaScriptBundle(bundle.OutputFileName, bundle.InputFiles.ToArray());
                }
            }
        });

[mrdnote]

This PR fixes the problem by always prefixing a slash, but what if you DO want the bundle to be on a relative path? The fix should check if the globbing pattern contains the prefix, and only prepend it when that's the case.

[dean-shanghai]

This PR fixes the problem by always prefixing a slash, but what if you DO want the bundle to be on a relative path? The fix should check if the globbing pattern contains the prefix, and only prepend it when that's the case.

check on what standard? there is no extra info for you to know whether to add the slash or not.

you can use the bundle (release or dev mode) on root level pages (www.domain.com/aaa), or pages in subfolders (www.domain.com/aaa/bbb), so relative path will cause problems.

I can think of two ways to solve this problem:

1. always generate relative paths to the root directory (not to the current directory), which is the easiest way, everyone follow this rule and it's ok;
2. add flags (indicating whether or not to add this prefix slash) to every config node in the bundleconfig.json file?

[mrdnote]

Check on whether the globbing pattern is relative or not. If it contains a forward slash, also apply this slash to the output files, if not, then don't apply it. I think this can be achieved inside Asset.ExpandGlobs.

[Nouwan]

Seems quite possible that this fixes #199 Is there anything I can do to help get this pr merged?