Modularize URI.js

[jgornick]

It would be nice if URI.js was split out in modules per URI component. For example, a user may only need to manipulate a query string with URI.js. If the user were able to include the source that is used to parse and manipulate a query string, it would not require the user to include the entire library.

Thoughts?

[rodneyrehm]

Yes, I have had that need myself. I've ended up not using URI.js because loading the entire lib for something as "simple" as absoluteTo was not worth it.

I have to admit that I'm at a loss how to even begin restructuring URI.js into small components. I've looked at jQuery but never figured out how their build really works. (might have to do with the fact that I only spent an hour before being pulled away from it…)

I was about to attempt splitting things up and using simple concatenation / variable replacement like MarionetteJS to at least get the benefit of smaller files…

Are you asking because you want to work on this, or are you asking because you want someone to work on this?

[jgornick]

@rodneyrehm It's not that I don't want to work on it 😄

I've always liked how modular Lo-Dash is (https://lodash.com/custom-builds). That might be a good pattern to look at.

I could see something like uri-js category=query to do a custom build for query parsing and manipulation.

I'd like to discuss this a little more. I'll spend some time really looking at the URI.js source to see if I can come up with any ideas how to split out the code.

[barneycarroll]

@rodneyrehm there's another project I'm a big fan of – Sinon.js – that has similar issues to what URIjs is facing: outdated and fragile modularization methods, constant hotfixes and support tickets, backward-compatibility concerns – and yet a pressing need to sort all that out so they can make future development smoother on a feature-by-feature level. They've attempted to branch this several times but bug fixes and feature requests always trump them, so they decided that this would require a new version and a new repo (and probably some breaking API changes). Of course, they still haven't solved the eternal problem of where to find enough time to build it :P.

I would be up for working on this in principle, because I strongly believe that many of the most difficult issues with URIjs (and URIs in general) have highly specific assumptions and use cases and that life would be easier for people if they could mix and match the bits they wanted without core concerns based on other assumptions and use cases getting in their way.

In practice it's a lot more difficult than that because most people do come to URIjs thinking 'whatever my URI-related problem is, this should solve it' and many of what might seem like distinct 'parts' of URI actually need to be inter-aware in order to produce the expected results – eg creating a workable URIjs API that can parse queries but ditches everything to do with domains & resources isn't as simple as just chucking most stuff out. And, presumably, when you decide that you want fragment abuse and query parsing, you would still want URI( String ) to parse for both. How that works isn't trivial. At a first pass, I'm imagining a string parsing engine to have conditional checks for optional components etc. It could get ugly!

What do we think the separateable components are?

[rodneyrehm]

as a first step I'd like to make every method live in its own file and declare its dependencies (basically other functions, parts of the parser, etc). All that is then assembled into the URIjs you know today. we can then talk about build-options to throw out undesired components. Or you can access a core function like uri/core/relativeTo directly, because the internals know their dependencies, it would only load the components you need to perform that particular task.

That basically is what the jquery build system is doing. It's not rocket science - I just haven't got the time to dig into this at the moment.

[barneycarroll]

As far as I see it there are 3 possible first steps:

1. Create a modular fork (and wait for merges to become a full-time job ;)
2. Create a new repo for URIjs 2.0 and set out writing pseudo-code
   acceptance tests for integrating modules
3. Create a new repo for 2.0 core and separate repos for each feature (each
   of which would depend on core) - this way people can npm require the bits
   they want seamlessly during dev

I would strongly urge for option 3 :)
On 22 Oct 2014 18:05, "Rodney Rehm" notifications@github.com wrote:

as a first step I'd like to make every method live in its own file and
declare its dependencies (basically other functions, parts of the parser,
etc). All that is then assembled into the URIjs you know today. we can then
talk about build-options to throw out undesired components. Or you can
access a core function like uri/core/relativeTo directly, because the
internals know their dependencies, it would only load the components you
need to perform that particular task.

That basically is what the jquery build system is doing. It's not rocket
science - I just haven't got the time to dig into this at the moment.

—
Reply to this email directly or view it on GitHub
#172 (comment).

[adoyle-h]

Currently, the full featured urijs (v1.18.4) is large.

• URI.min.js, source from npm package: 45KB
• URI.js, source from npm package: 62KB
• Base URI.js with No Fragment abuse, no-gzipped, builded in http://medialize.github.io/URI.js/build.html: 29KB

It would be great that separating urijs into packages by features, and each package could be required independently. Read lodash for references.

How is the process going in v2.0.0? Could you write down the v2 plan in README or WIKI or Issue? @rodneyrehm

[rodneyrehm]

How is the process going in v2.0.0?

not started

Could you write down the v2 plan in README or WIKI or Issue?

Don't really have a plan yet. But v2 will be ES6 and use ES6 modules internally.

[ArmorDarks]

It would be great to see that feature!

Library seems to be great, but indeed is too heavy-packed for most client-side tasks.

As already mentioned, lodash represents great example of modularizing everything. It especially helps when you use JSPM (with Rollup under the hood) with tree shaking.

[rodneyrehm]

I'm painfully aware of both the current size and the benefits of modules. However I haven't been able to siphon off the time to make significant progress on this front.

[MrBrax]

No way of doing this yet? I'm experimenting with webpack but i don't need any of the extra components in this, and i can't figure out how it's requiring/importing the files.

[rodneyrehm]

not yet, sorry. You might be able to use webpack.IgnorePlugin to exclude the files you don't need.

[MrBrax]

Then URI errors about not finding the files. I'll look for another addon.

[MrBrax]

What i don't really understand is, why does the closure compiler/build tool not error? Are they not doing basically the same procedure?

[a-x-]

It will be cool to enable Webpack tree shaking by providing separate es6 exports

[a-x-]

e.g.

import { path } from 'urijs'
path(url)

before:

import URI from 'urijs'
URI.path(url)

I need to reimplement every day some url utils because I don't want to add big urijs chunk for one or two functions

[ethanroday]

Would love to see this happen!

[iggant]

core-js@3 now implement (as polifill)URL and URLSearchParams spec

We can relay to this specs