Can we add exports field for this package? about classnames

[jonkoops]

Upon closer consideration, I do believe we could attempt to land this as a non-breaking change. Theoretically, if the exported surface is equivalent to that which is currently exposed, this should work as expected. I am going to give this a shot.

[jonkoops]

Yes, that is possible, but in practice I have had several bug reports on other packages I maintain when this field was introduced. Nothing wrong with putting this in a major version.

My intention is to try and fix all the existing open issues and then move to the tasks that would involve a potential major version bump such as this one.

[jonkoops]

I think this is a good idea, it's certainly where modern package development is going. In my experience applying this field it is a breaking change due to inconsistent behaviour of tools that consume it, so I will mark it as such.

[krutoo]

@jonkoops i dont sure that is breaks packward compatibilty, you can add exports field like its done on react for example:

{
  "exports": {
    ".": {
      "default": "./index.js"
    },
    "./index.js": {
      "default": "./index.js"
    },
    "./bind": {
      "default": "./bind.js"
    },
    "./bind.js": {
      "default": "./bind.js"
    },
    "./dedupe": {
      "default": "./dedupe.js"
    },
    "./dedupe.js": {
      "default": "./dedupe.js"
    }
  },
}

if i properly understand